bug#22034: time-utc->date shows bogus zone-dependent leap second

bug#22034: time-utc->date shows bogus zone-dependent leap second

[Zefram]

time-utc->date seems to think that a leap second occurs at a different
time in each time zone:

scheme@(guile-user)> (use-modules (srfi srfi-19))
scheme@(guile-user)> (define (tdate d) (write (list (date->string d "~4") (date->string (time-utc->date (date->time-utc d) 3600) "~4"))) (newline))
scheme@(guile-user)> (tdate (make-date 0 59 59 22 30 6 2012 0))
("2012-06-30T22:59:59Z" "2012-06-30T23:59:59+0100")
scheme@(guile-user)> (tdate (make-date 0 0 0 23 30 6 2012 0))
("2012-06-30T23:00:00Z" "2012-06-30T23:59:60+0100")
scheme@(guile-user)> (tdate (make-date 0 1 0 23 30 6 2012 0))
("2012-06-30T23:00:01Z" "2012-07-01T00:00:01+0100")

These are three consecutive seconds that occur an hour before a genuine
leap second (at 23:59:60Z).  Observe that time-utc->date, applied to the
middle second, describes it as a leap second happening at 23:59:60+01:00,
which is bogus.  Describing the same seconds on input as a date structure
with a non-zero zone offset produces the same wrong output, and requesting
output with a different zone offset changes which second is affected.
The faulty output is always 23:59:60 in the output zone.

Matching up with this, the actual leap second is never correctly described
with a non-zero zone offset.  It should be, for example, 00:59:60+01:00.
However, probing for this side of the problem also runs into the
round-tripping failure that I described in bug#22033.

-zefram

bug#22034: time-utc->date shows bogus zone-dependent leap second

[Mark H Weaver]

Zefram <zefram@fysh.org> writes:

> time-utc->date seems to think that a leap second occurs at a different
> time in each time zone:
>
> scheme@(guile-user)> (use-modules (srfi srfi-19))
> scheme@(guile-user)> (define (tdate d) (write (list (date->string d "~4") (date->string (time-utc->date (date->time-utc d) 3600) "~4"))) (newline))
> scheme@(guile-user)> (tdate (make-date 0 59 59 22 30 6 2012 0))
> ("2012-06-30T22:59:59Z" "2012-06-30T23:59:59+0100")
> scheme@(guile-user)> (tdate (make-date 0 0 0 23 30 6 2012 0))
> ("2012-06-30T23:00:00Z" "2012-06-30T23:59:60+0100")
> scheme@(guile-user)> (tdate (make-date 0 1 0 23 30 6 2012 0))
> ("2012-06-30T23:00:01Z" "2012-07-01T00:00:01+0100")
>
> These are three consecutive seconds that occur an hour before a genuine
> leap second (at 23:59:60Z).  Observe that time-utc->date, applied to the
> middle second, describes it as a leap second happening at 23:59:60+01:00,
> which is bogus.  [...]

This is fixed by commit 5106377a3460e1e35daf14ea6edbe80426347155 on the
stable-2.2 branch.

> Matching up with this, the actual leap second is never correctly described
> with a non-zero zone offset.  It should be, for example, 00:59:60+01:00.

If I understand correctly, 'time-utc->date' should never return a date
object with 60 in the seconds field, because those extra seconds have no
representation in time-utc.  They only have representations in time-tai
and time-monotonic.

Anyway, thanks very much for these reports!  I'm closing this bug now,
but feel free to reopen if you think there are still issues to resolve.

      Mark

bug#22034: time-utc->date shows bogus zone-dependent leap second

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 1167 bytes --]

On Sat, Oct 20, 2018 at 5:43 PM Mark H Weaver <mhw@netris.org> wrote:

If I understand correctly, 'time-utc->date' should never return a date
> object with 60 in the seconds field, because those extra seconds have no
> representation in time-utc.  They only have representations in time-tai
> and time-monotonic.
>

As I understand it, this is incorrect.  UTC days can contain either 86400
or 86401 seconds (or in principle a different number), depending on whether
the day has a leap second.  It is *Posix* time, not UTC time, that contains
a fixed number of seconds per day, or more accurately that assigns a label
from 0 to 864399 to the seconds of a day, and can assign the same label to
more than one second (or in principle could assign one or more labels to no
second) on a leap-second day. Consequently, a broken-down time can indeed
return 60 in the seconds field, but only for a UTC clock, never for a Posix
clock.

This error is repeated in a number of your later messages, but I'll respond
only to this one.

-- 
John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
Tautology is something that is tautological.  --Francois-Rene Rideau

[-- Attachment #2: Type: text/html, Size: 1712 bytes --]

bug#22034: time-utc->date shows bogus zone-dependent leap second

[Mark H Weaver]

John Cowan <cowan@ccil.org> writes:

> On Sat, Oct 20, 2018 at 5:43 PM Mark H Weaver <mhw@netris.org> wrote:
>
>  If I understand correctly, 'time-utc->date' should never return a date
>  object with 60 in the seconds field, because those extra seconds have no
>  representation in time-utc.  They only have representations in time-tai
>  and time-monotonic.
>
> As I understand it, this is incorrect.  UTC days can contain either
> 86400 or 86401 seconds (or in principle a different number),

If you're talking about TAI seconds, then I agree.  However, the
'time-utc' representation in SRFI-19 is not a count of TAI seconds, but
rather a count _UTC_ seconds since the POSIX epoch.

Under the current "leap second" method of keeping UTC within 0.9 seconds
of UT1, UTC days contain either 86399, 86400, or 86401 _TAI_ seconds.
So far, all leap seconds have increased the TAI-UTC delta, but if the
(irregular) rotation rate of the Earth speeds up, we might some day need
a leap second that decreases the TAI-UTC delta.

Universal Time (UT) is not a measure of physical time, but rather is a
measure of the rotation angle of the Earth with respect to distant
quasars.  A UT second is identified with a fixed amount of rotation of
the Earth, which equals 1/86400 of a mean solar day.  That's why every
day has 86400 UT seconds.  UTC is kept within 0.9 seconds of UT1 (a
version of UT with certain corrections applied), so over long time
periods, with the leap seconds taken into account, UTC seconds are equal
to UT seconds.

       Mark

bug#22034: time-utc->date shows bogus zone-dependent leap second

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 1641 bytes --]

On Mon, Oct 22, 2018 at 2:12 AM Mark H Weaver <mhw@netris.org> wrote:

Universal Time (UT) is not a measure of physical time, but rather is a
> measure of the rotation angle of the Earth with respect to distant
> quasars.  A UT second is identified with a fixed amount of rotation of
> the Earth, which equals 1/86400 of a mean solar day.  That's why every
> day has 86400 UT seconds.


Quite right.  Buit the whole point of UTC is that its seconds are not
angles,
but SI = TAI seconds.  There are a variable number of these in a day, and
a UTC clock will indeed report 23:59:60 at the end of a day with a leap
second in it (and other civil-time clocks will similarly report :60 in
whatever
hour, according to their timezone offsets).  See
<https://en.wikipedia.org/wiki/Leap_second#/media/File:Leapsecond2016.png>,
which is a screenshot of https://time.gov displaying the last leap second.

Now there are indeed exactly 86400 _Posix_ seconds in a day, which is
achieved by giving two seconds the same label if it is a leap day.  But
that has nothing to do with either TAI or UTC.


> UTC is kept within 0.9 seconds of UT1 (a
> version of UT with certain corrections applied), so over long time
> periods, with the leap seconds taken into account, UTC seconds are equal
> to UT seconds.
>

No, in the long run UTC time is equal to UT1 time.  That's not the same
thing at all.

-- 
John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
I am expressing my opinion.  When my honorable and gallant friend is
called, he will express his opinion.  This is the process which we
call Debate.                   --Winston Churchill

[-- Attachment #2: Type: text/html, Size: 2619 bytes --]

bug#22034: time-utc->date shows bogus zone-dependent leap second

[Mark H Weaver]

Hi John,

John Cowan <cowan@ccil.org> writes:

> On Mon, Oct 22, 2018 at 2:12 AM Mark H Weaver <mhw@netris.org> wrote:
>
>  Universal Time (UT) is not a measure of physical time, but rather is a
>  measure of the rotation angle of the Earth with respect to distant
>  quasars.  A UT second is identified with a fixed amount of rotation of
>  the Earth, which equals 1/86400 of a mean solar day.  That's why every
>  day has 86400 UT seconds.  
>
> Quite right.  Buit the whole point of UTC is that its seconds are not angles,
> but SI = TAI seconds.

I believe you're making a subtle error in your identification of UTC
seconds with TAI seconds.  It might be helpful to consider an analogy to
spatial measurement.

A TAI clock aims to measure the current TAI time, i.e. to measure the
time interval between the epoch and _you_ in units of TAI seconds,
i.e. SI seconds as observed on the geoid.

In spatial terms, a TAI clock is analogous to a very precise measuring
tape which aims to measure the distance between you and an fixed
conventional point in space, analogous to the TAI epoch.

In this analogy, a UTC clock is analogous to an equally precise
measuring tape that is _almost_ identical to the TAI analogue measuring
tape, but subtly different.  If we place the two measuring tapes side by
side and ignore pre-1972, we see that the markings are in _precisely_
the same positions along the entire length of the tape, without the
slightest deviation, even over long distances.

The difference between the two measuring tapes is that they assign
different numbers to the markings, and moreover that the UTC analogue
has a small handful of places where two adjacent markings have the same
number assigned, and all subsequent numbers are shifted by 1.  Such a
place might look something like this:

  126230388 |--
  126230389 |--
  126230390 |------------
  126230391 |--
  126230392 |--
  126230393 |--
  126230394 |--
  126230395 |------
  126230396 |--
  126230397 |--
  126230398 |--
  126230399 |--
  126230400 |------------
  126230400 |------------
  126230401 |--
  126230402 |--
  126230403 |--
  126230404 |--
  126230405 |------
  126230406 |--
  126230407 |--
  126230408 |--
  126230409 |--
  126230410 |------------
  126230411 |--
  126230412 |--

By asserting that UTC seconds are the same as TAI seconds, you're
emphasizing that the distance between any two adjacent markings are
precisely the same on the two measuring tapes.

What I'm trying to say is that when you use these two measuring tapes to
measure the interval between two arbitrary points, they will give
different answers, unless the entire interval happens to be between two
adjacent leap seconds (and post-1971).

I think it's highly questionable to claim that these two measuring tapes
measure the same units, given that when they are actually used to
measure intervals, they give different answers, and moreover that the
discrepancy grows without bound as larger intervals are measured, even
in an idealized thought experiment.

> There are a variable number of these in a day, and a UTC clock will
> indeed report 23:59:60 at the end of a day with a leap second in it

That's something that can be done when you convert TIME-TAI into a UTC
date, and indeed 'time-tai->date' from SRFI-19 will do this:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> ,pp (map (lambda (n)
                                (let* ((tai (make-time time-tai 0 n)))
                                  (list (time-second tai)
                                        (date->string (time-tai->date tai 0)
                                                      "~4"))))
                              (iota 5 126230410))
$1 = ((126230410 "1973-12-31T23:59:58Z")
      (126230411 "1973-12-31T23:59:59Z")
      (126230412 "1973-12-31T23:59:60Z")
      (126230413 "1974-01-01T00:00:00Z")
      (126230414 "1974-01-01T00:00:01Z"))
--8<---------------cut here---------------end--------------->8---


However, let's return to our disagreement which started this digression:

> On Sat, Oct 20, 2018 at 5:43 PM Mark H Weaver <mhw@netris.org> wrote:
>
>  If I understand correctly, 'time-utc->date' should never return a date
>  object with 60 in the seconds field, because those extra seconds have no
>  representation in time-utc.  They only have representations in time-tai
>  and time-monotonic.
>
> As I understand it, this is incorrect.  UTC days can contain either
> 86400 or 86401 seconds (or in principle a different number), depending
> on whether the day has a leap second.

You seem to be asserting above that TIME-UTC _does_ have representations
of the extra leap seconds.  That is simply not true.  It's true that
*date objects* for UTC, broken down into separate fields, are able to
represent the leap seconds by putting 60 in the seconds field.  However,
TIME-UTC, represented as a single number of seconds since the epoch, is
_not_ able to represent them.

Let's look at a small interval near a leap second, in TIME-TAI,
TIME-UTC, and the corresponding date objects expressed in UTC:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> ,pp (map (lambda (n)
                                (let* ((tai (make-time time-tai 0 n))
                                       (utc (time-tai->time-utc tai)))
                                  (list (time-second tai)
                                        (time-second utc)
                                        (date->string (time-tai->date tai 0)
                                                      "~4"))))
                              (iota 5 126230410))
$2 = ((126230410 126230398 "1973-12-31T23:59:58Z")
      (126230411 126230399 "1973-12-31T23:59:59Z")
      (126230412 126230400 "1973-12-31T23:59:60Z")
      (126230413 126230400 "1974-01-01T00:00:00Z")
      (126230414 126230401 "1974-01-01T00:00:01Z"))
--8<---------------cut here---------------end--------------->8---

As you can see, 1973-12-31T23:59:60Z and 1974-01-01T00:00:00Z have the
same representation in TIME-UTC.  This is an unavoidable consequence of
the fact that TAI-UTC=12 shortly before midnight 1974-01-01 UTC, and
TAI-UTC=13 shortly after.

This is the basis for my claim that TIME-UTC is unable to represent leap
seconds, and that 'time-utc->date' should never return 60 in the seconds
field.  In theory, we could have it return 60 in the seconds field when
the input is 126230400 UTC seconds, but if we did that, then we'd be
skipping 1974-01-01T00:00:00Z.

So, what about my claim that every UTC day has 86400 UTC seconds,
although UTC days can have between 86399 and 86401 TAI seconds?  Let's
look at a similar table as above, but for the previous day:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> ,pp (map (lambda (n)
                                (let* ((tai (make-time time-tai 0 n))
                                       (utc (time-tai->time-utc tai)))
                                  (list (time-second tai)
                                        (time-second utc)
                                        (date->string (time-tai->date tai 0)
                                                      "~4"))))
                              (iota 5 (- 126230410 86400)))
$3 = ((126144010 126143998 "1973-12-30T23:59:58Z")
      (126144011 126143999 "1973-12-30T23:59:59Z")
      (126144012 126144000 "1973-12-31T00:00:00Z")
      (126144013 126144001 "1973-12-31T00:00:01Z")
      (126144014 126144002 "1973-12-31T00:00:02Z"))
--8<---------------cut here---------------end--------------->8---

The difference between the TIME-TAI values for 1973-12-31T00:00:00Z and
1974-01-01T00:00:00Z is 126230413-126144012 = 86401, but the difference
between the corresponding TIME-UTC values is 126230400-126144000 =
86400.

Does that make sense?

    Regards,
      Mark

bug#22034: time-utc->date shows bogus zone-dependent leap second

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 3156 bytes --]

On Sun, Oct 28, 2018 at 4:40 PM Mark H Weaver <mhw@netris.org> wrote:

I believe you're making a subtle error in your identification of UTC
> seconds with TAI seconds.


And I in turn think you (or perhaps someone else)are making an error
in your use of the term "UTC".


> A TAI clock aims to measure the current TAI time, i.e. to measure the
> time interval between the epoch and _you_ in units of TAI seconds,
> i.e. SI seconds as observed on the geoid.
>
> In spatial terms, a TAI clock is analogous to a very precise measuring
> tape which aims to measure the distance between you and an fixed
> conventional point in space, analogous to the TAI epoch.
>

We agree so far.


> In this analogy, a UTC clock is analogous to an equally precise
> measuring tape that is _almost_ identical to the TAI analogue measuring
> tape, but subtly different.  If we place the two measuring tapes side by
> side and ignore pre-1972, we see that the markings are in _precisely_
> the same positions along the entire length of the tape, without the
> slightest deviation, even over long distances.
>
> The difference between the two measuring tapes is that they assign
> different numbers to the markings, and moreover that the UTC analogue
> has a small handful of places where two adjacent markings have the same
> number assigned, and all subsequent numbers are shifted by 1.


Now I think you are entirely right here, modulo a single term: what you are
calling "UTC", I call (and I think correctly), "Posix".  It is Posix time
that
has two identical adjacent markings.

  126230400 |------------
>   126230400 |------------
>

The numbers here are not UTC seconds since the Epoch, but Posix seconds
since the Epoch.  In short, there are exactly 86400 Posix seconds in a mean
solar day, whereas in UTC reckoning there are exactly 1440 minutes, of
which
some may contain more (or less) than 60 seconds.  That is why UTC clocks
displayed 2016-12-13T23:59:60 during the last leap second.  Computer clocks
are normally Posix rather than UTC clocks, and the difference does not
matter
very often.



> $1 = ((126230410 "1973-12-31T23:59:58Z")
>       (126230411 "1973-12-31T23:59:59Z")
>       (126230412 "1973-12-31T23:59:60Z")
>       (126230413 "1974-01-01T00:00:00Z")
>       (126230414 "1974-01-01T00:00:01Z"))
> --8<---------------cut here---------------end--------------->8--


Good.


> >  If I understand correctly, 'time-utc->date' should never return a date
>
>  object with 60 in the seconds field, because those extra seconds have no
> >  representation in time-utc.  They only have representations in time-tai
> >  and time-monotonic.
>

Same story.  Leap seconds have no representation in Posix time, but they
do in UTC time.


> As you can see, 1973-12-31T23:59:60Z and 1974-01-01T00:00:00Z have the
> same representation in TIME-UTC.


That is because what is called UTC time is in fact Posix time.

-- 
John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
It was impossible to inveigle
Georg Wilhelm Friedrich Hegel
Into offering the slightest apology
For his Phenomenology.                      --W. H. Auden, from "People"
(1953)

[-- Attachment #2: Type: text/html, Size: 5151 bytes --]

bug#22034: time-utc->date shows bogus zone-dependent leap second

[Mark H Weaver]

Hi John,

John Cowan <cowan@ccil.org> writes:

> On Sun, Oct 28, 2018 at 4:40 PM Mark H Weaver <mhw@netris.org> wrote:
>
>  The difference between the two measuring tapes is that they assign
>  different numbers to the markings, and moreover that the UTC analogue
>  has a small handful of places where two adjacent markings have the same
>  number assigned, and all subsequent numbers are shifted by 1.
>
> Now I think you are entirely right here, modulo a single term: what you are
> calling "UTC", I call (and I think correctly), "Posix".  It is Posix time that
> has two identical adjacent markings.
>
>    126230400 |------------
>    126230400 |------------
>
> The numbers here are not UTC seconds since the Epoch, but Posix seconds
> since the Epoch.

Here's a more detailed display of the same leap second that I chose for
my example, which you quoted above:

+-----------------------------------------------------------+
|      TAI seconds  UTC seconds                             |
|         since       since                                 |
|     midnight UTC  midnight UTC                            |
|      1 Jan 1970   1 Jan 1970    Result of 'time-tai->date'|
|-----------------------------------------------------------|
|$2 = ((126230410    126230398    "1973-12-31T23:59:58Z")   |
|      (126230411    126230399    "1973-12-31T23:59:59Z")   |
|      (126230412    126230400    "1973-12-31T23:59:60Z")   |
|      (126230413    126230400    "1974-01-01T00:00:00Z")   |
|      (126230414    126230401    "1974-01-01T00:00:01Z"))  |
+-----------------------------------------------------------+

The table above illustrates my understanding of the relationship between
"TAI seconds since midnight UTC on 1 Jan 1970", "UTC seconds since
midnight UTC on 1 Jan 1970" and the date object expressed in UTC.  See
my previous email for the code to produce the table above using SRFI-19.

If I understand correctly, based on your last sentence that I quoted
above, you believe that the numbers I've given in the second column are
not UTC seconds since the epoch, and that there is confusion here
between UTC seconds and Posix seconds.

Can you please be more concrete and tell me what numbers you think
should be in the second column, to properly reflect the column heading?
I'm not asking for a prose description, but for the actual numbers.

If the table above is incorrect, then it would be good to report the
problem to the SRFI-19 mailing list, because the current SRFI-19
reference implementation produces the same table.

     Thanks,
       Mark

bug#22034: time-utc->date shows bogus zone-dependent leap second

[Mark H Weaver]

Mark H Weaver <mhw@netris.org> writes:

> John Cowan <cowan@ccil.org> writes:
>
>> On Sun, Oct 28, 2018 at 4:40 PM Mark H Weaver <mhw@netris.org> wrote:
>>
>>  The difference between the two measuring tapes is that they assign
>>  different numbers to the markings, and moreover that the UTC analogue
>>  has a small handful of places where two adjacent markings have the same
>>  number assigned, and all subsequent numbers are shifted by 1.
>>
>> Now I think you are entirely right here, modulo a single term: what you are
>> calling "UTC", I call (and I think correctly), "Posix".  It is Posix time that
>> has two identical adjacent markings.
>>
>>    126230400 |------------
>>    126230400 |------------
>>
>> The numbers here are not UTC seconds since the Epoch, but Posix seconds
>> since the Epoch.
>
> Here's a more detailed display of the same leap second that I chose for
> my example, which you quoted above:
>
> +-----------------------------------------------------------+
> |      TAI seconds  UTC seconds                             |
> |         since       since                                 |
> |     midnight UTC  midnight UTC                            |
> |      1 Jan 1970   1 Jan 1970    Result of 'time-tai->date'|
> |-----------------------------------------------------------|
> |$2 = ((126230410    126230398    "1973-12-31T23:59:58Z")   |
> |      (126230411    126230399    "1973-12-31T23:59:59Z")   |
> |      (126230412    126230400    "1973-12-31T23:59:60Z")   |
> |      (126230413    126230400    "1974-01-01T00:00:00Z")   |
> |      (126230414    126230401    "1974-01-01T00:00:01Z"))  |
> +-----------------------------------------------------------+
>
> The table above illustrates my understanding of the relationship between
> "TAI seconds since midnight UTC on 1 Jan 1970", "UTC seconds since
> midnight UTC on 1 Jan 1970" and the date object expressed in UTC.  See
> my previous email for the code to produce the table above using SRFI-19.

Sorry, I made a mistake above.  Where I wrote:

  "TAI seconds since midnight UTC on 1 Jan 1970"

I should have written:

  "TAI seconds since midnight TAI on 1 Jan 1970"

I'm not aware of any other mistakes in my last message.

Given that correction to the heading over the first column, I'd still
like to know what numbers you believe should be in a corrected version
of the table above.

I admit that this is a surprisingly challenging subject, but I think
it's important to get to the bottom of this.  If there's a deep problem
in SRFI-19 regarding its interpretation of UTC seconds, we need to know
about it and fix it.  This issue affects the entire Scheme community.

     Thanks,
       Mark

bug#22034: time-utc->date shows bogus zone-dependent leap second

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 1539 bytes --]

On Mon, Oct 29, 2018 at 3:17 AM Mark H Weaver <mhw@netris.org> wrote:

Can you please be more concrete and tell me what numbers you think
> should be in the second column, to properly reflect the column heading?
> I'm not asking for a prose description, but for the actual numbers.
>

Here you go:

+-------------------------------------------------------------------------+
|      TAI seconds  UTC seconds Posix seconds                             |
|         since       since        since                                  |
|     midnight TAI  midnight UTC midnight UTC                             |
|      1 Jan 1970   1 Jan 1970   1 Jan 1970    Result of 'time-tai->date' |
|-------------------------------------------------------------------------|
|$2 = ((126230410    126230398    126230398    "1973-12-31T23:59:58Z")    |
|      (126230411    126230399    126230399    "1973-12-31T23:59:59Z")    |
|      (126230412    126230400    126230400    "1973-12-31T23:59:60Z")    |
|      (126230413    126230401    126230400    "1974-01-01T00:00:00Z")    |
|      (126230414    126230402    126230401    "1974-01-01T00:00:01Z"))   |
+-------------------------------------------------------------------------+

So as you see leap seconds are included in both the TAI and the UTC count,
but not in the Posix count.

-- 
John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
I could dance with you till the cows come home.  On second thought,
I'd rather dance with the cows when you come home.
        --Rufus T. Firefly

[-- Attachment #2: Type: text/html, Size: 2478 bytes --]

bug#22034: time-utc->date shows bogus zone-dependent leap second

[Mark H Weaver]

Hi John,

John Cowan <cowan@ccil.org> writes:

> On Mon, Oct 29, 2018 at 3:17 AM Mark H Weaver <mhw@netris.org> wrote:
>
>  Can you please be more concrete and tell me what numbers you think
>  should be in the second column, to properly reflect the column heading?
>  I'm not asking for a prose description, but for the actual numbers.
>
> Here you go:
>
> +-------------------------------------------------------------------------+
> |      TAI seconds  UTC seconds Posix seconds                             |
> |         since       since        since                                  |
> |     midnight TAI  midnight UTC midnight UTC                             |
> |      1 Jan 1970   1 Jan 1970   1 Jan 1970    Result of 'time-tai->date' |
> |-------------------------------------------------------------------------|
> |$2 = ((126230410    126230398    126230398    "1973-12-31T23:59:58Z")    |
> |      (126230411    126230399    126230399    "1973-12-31T23:59:59Z")    |
> |      (126230412    126230400    126230400    "1973-12-31T23:59:60Z")    |
> |      (126230413    126230401    126230400    "1974-01-01T00:00:00Z")    |
> |      (126230414    126230402    126230401    "1974-01-01T00:00:01Z"))   |
> +-------------------------------------------------------------------------+

Thank you, this is helpful.

> So as you see leap seconds are included in both the TAI and the UTC count,
> but not in the Posix count.

According to <http://maia.usno.navy.mil/ser7/tai-utc.dat>, the value of
TAI-UTC should change from 12 to 13 at JD 2442048.5, i.e. at midnight
UTC on 1 January 1974.  The same fact is shown on the graph at the
bottom of this page:

  http://jjy.nict.go.jp/mission/page1-e.html

In the values you proposed above, TAI-UTC is 12 uniformly throughout,
both before and after the leap second.

If you believe that TAI-UTC should not change at JD 2442048.5, then for
consistency, you should believe that it doesn't change at JD 2441683.5,
the previous leap second one year earlier:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> ,pp (map (lambda (n)
                                (let* ((tai (make-time time-tai 0 n))
                                       (utc (time-tai->time-utc tai)))
                                  (list (time-second tai)
                                        (time-second utc)
                                        (date->string (time-tai->date tai 0)
                                                      "~4"))))
                              (iota 5 94694409))
$1 = ((94694409 94694398 "1972-12-31T23:59:58Z")
      (94694410 94694399 "1972-12-31T23:59:59Z")
      (94694411 94694400 "1972-12-31T23:59:60Z")
      (94694412 94694400 "1973-01-01T00:00:00Z")
      (94694413 94694401 "1973-01-01T00:00:01Z"))
--8<---------------cut here---------------end--------------->8---

If we apply the same changes here that you did above, with UTC=Posix at
the top and UTC=Posix+1 at the bottom, it would look like this:

> +-------------------------------------------------------------------------+
> |      TAI seconds  UTC seconds Posix seconds                             |
> |         since       since        since                                  |
> |     midnight TAI  midnight UTC midnight UTC                             |
> |      1 Jan 1970   1 Jan 1970   1 Jan 1970    Result of 'time-tai->date' |
> |-------------------------------------------------------------------------|
> |$2 = ((94694409    94694398    94694398    "1972-12-31T23:59:58Z")    |
> |      (94694410    94694399    94694399    "1972-12-31T23:59:59Z")    |
> |      (94694411    94694400    94694400    "1972-12-31T23:59:60Z")    |
> |      (94694412    94694401    94694400    "1973-01-01T00:00:00Z")    |
> |      (94694413    94694402    94694401    "1973-01-01T00:00:01Z"))   |
> +-------------------------------------------------------------------------+

Is that a reasonable extrapolation of what you did?

Note that in the table above, TAI-UTC is 11 uniformly throughout.  This
raises of the question of how to combine these two tables into a
coherent whole.  In order to produce a larger table that includes both
of these excerpts and everything in between, TAI-UTC would need to
change from 11 to 12 somewhere in the middle.

Do you see the problem?

Would you like to make another suggestion of what values should go in
the second column of these two tables?

     Thanks,
       Mark