bug#26164: time-difference mishandles leap seconds

bug#26164: time-difference mishandles leap seconds

[Zefram]

Computing the duration of the period between two UTC times, using
SRFI-19 mechanisms:

scheme@(guile-user)> (use-modules (srfi srfi-19))
scheme@(guile-user)> (define t0 (date->time-utc (make-date 0 59 59 23 30 6 2012 0))) 
scheme@(guile-user)> (define t1 (date->time-utc (make-date 0 1 0 0 1 7 2012 0)))
scheme@(guile-user)> (time-difference t1 t0)
$1 = #<time type: time-duration nanosecond: 0 second: 2>

The two times are 2012-06-30T23:59:59 and 2012-07-01T00:00:01, so at
first glance one would expect the duration to be 2 s as shown above,
the two seconds being 23:59:59 and 00:00:00.  But in fact there was
a leap second 2012-06-30T23:59:60, so the duration of this period is
actually 3 s.  The SRFI-19 library is aware of this leap second, and
will compute the duration correctly if it's translated into TAI:

scheme@(guile-user)> (time-difference (time-utc->time-tai t1) (time-utc->time-tai t0))
$2 = #<time type: time-duration nanosecond: 0 second: 3>

The original computation in UTC space should yield a result of 3 s,
not the 2 s that it did.  Since 1972, the seconds of UTC are of exactly
the same duration as the seconds of TAI.  (They're also phase-locked to
TAI seconds.)  Thus the period of three TAI seconds is also a period of
three UTC seconds.  It is not somehow squeezed into two UTC seconds.

-zefram

bug#26164: time-difference mishandles leap seconds

[Andy Wingo]

On Sat 18 Mar 2017 23:41, Zefram <zefram@fysh.org> writes:

> Computing the duration of the period between two UTC times, using
> SRFI-19 mechanisms:
>
> scheme@(guile-user)> (use-modules (srfi srfi-19))
> scheme@(guile-user)> (define t0 (date->time-utc (make-date 0 59 59 23 30 6 2012 0))) 
> scheme@(guile-user)> (define t1 (date->time-utc (make-date 0 1 0 0 1 7 2012 0)))
> scheme@(guile-user)> (time-difference t1 t0)
> $1 = #<time type: time-duration nanosecond: 0 second: 2>
>
> The two times are 2012-06-30T23:59:59 and 2012-07-01T00:00:01, so at
> first glance one would expect the duration to be 2 s as shown above,
> the two seconds being 23:59:59 and 00:00:00.  But in fact there was
> a leap second 2012-06-30T23:59:60, so the duration of this period is
> actually 3 s.  The SRFI-19 library is aware of this leap second, and
> will compute the duration correctly if it's translated into TAI:
>
> scheme@(guile-user)> (time-difference (time-utc->time-tai t1) (time-utc->time-tai t0))
> $2 = #<time type: time-duration nanosecond: 0 second: 3>
>
> The original computation in UTC space should yield a result of 3 s,
> not the 2 s that it did.  Since 1972, the seconds of UTC are of exactly
> the same duration as the seconds of TAI.  (They're also phase-locked to
> TAI seconds.)  Thus the period of three TAI seconds is also a period of
> three UTC seconds.  It is not somehow squeezed into two UTC seconds.

Makes sense to me.  Would you like to submit a patch and test case?  I
would be happy to apply it.

Andy

bug#26164: time-difference mishandles leap seconds

[Zefram]

Andy Wingo wrote:
>Makes sense to me.  Would you like to submit a patch and test case?

This particular bug has interactions with other bugs that make me
uncomfortable about attempting to fix it right now.  The right way to
fix this is especially influenced by the approach taken to bug#22033 and
to the bug regarding pre-1972 UTC.  The latter I haven't even reported
yet because it's difficult to formulate in the presence of some of the
other UTC-related bugs such as bug#21911 and bug#21912.  So I think this
is one to postpone until some of those are out of the way.

-zefram

bug#26164: time-difference mishandles leap seconds

[Mark H Weaver]

Zefram <zefram@fysh.org> writes:

> Computing the duration of the period between two UTC times, using
> SRFI-19 mechanisms:
>
> scheme@(guile-user)> (use-modules (srfi srfi-19))
> scheme@(guile-user)> (define t0 (date->time-utc (make-date 0 59 59 23 30 6 2012 0))) 
> scheme@(guile-user)> (define t1 (date->time-utc (make-date 0 1 0 0 1 7 2012 0)))
> scheme@(guile-user)> (time-difference t1 t0)
> $1 = #<time type: time-duration nanosecond: 0 second: 2>
>
> The two times are 2012-06-30T23:59:59 and 2012-07-01T00:00:01, so at
> first glance one would expect the duration to be 2 s as shown above,
> the two seconds being 23:59:59 and 00:00:00.  But in fact there was
> a leap second 2012-06-30T23:59:60, so the duration of this period is
> actually 3 s.

You seem to be assuming that SRFI-19 durations should _always_ represent
intervals of TAI time.  While I agree that TAI time is often the right
choice for durations, there are other cases where monotonic time is a
better choice.  Currently, monotonic time == TAI time, but SRFI-19 makes
it clear that this needn't be the case, and at some point we might want
to change monotonic time to be _truly_ monotonic, even in cases where
the system clock jumps backward.

Durations in UTC time have uses as well.  For example, every UTC day has
exactly 86400 UTC seconds, so (make-time time-duration 0 86400) means 1
UTC day, when added to a UTC time.  This is a duration that, when added
to any UTC time, always leaves the time-of-day unchanged.  There is no
fixed duration of TAI time that has this property, because not all UTC
days have the same number of TAI seconds.

> [...]  Since 1972, the seconds of UTC are of exactly
> the same duration as the seconds of TAI.  (They're also phase-locked to
> TAI seconds.)  Thus the period of three TAI seconds is also a period of
> three UTC seconds.  It is not somehow squeezed into two UTC seconds.

I believe you are mistaken here.  Not all UTC seconds have the same
duration as a TAI second.  Some TAI seconds correspond to 0 UTC seconds,
and maybe some day there will be a TAI second that corresponds to 2 UTC
seconds.

Having said all of this, I should admit that I'm not an expert on time
standards, so perhaps I've misunderstood something.

What do you think?

      Mark

bug#26164: time-difference mishandles leap seconds

[Zefram]

Mark H Weaver wrote:
>You seem to be assuming that SRFI-19 durations should _always_ represent
>intervals of TAI time.

No, that is not my position.  Although SRFI-19 isn't entirely explicit
on this point, it is in the nature of the problem space that a duration
may be measured on any time scale, and it seems to be implied that
time-difference will determine the duration on the time scale of its
inputs.  Indeed, if the duration were always to be determined on one
specific scale then it would not be necessary for time-difference to
require its two inputs to be of the same time type.

With respect to UTC, my position is that time-difference on inputs of
type time-utc should determine the duration as measured in UTC seconds.
For times since 1972 this is always the same as the duration in TAI
seconds (elaborated further below).  For 1961 to 1971 UTC durations and
TAI durations differ, and that's the subject of my bug#26632.  Note that
in that bug report I explicitly converted time-utc->time-tai where I
wanted to determine a TAI duration.

>                                                       every UTC day has
>exactly 86400 UTC seconds,

No, that's not how UTC works.  There are some time scales derived from UTC
that have exactly 86400 seconds for each UTC day, such as Markus Kuhn's
UTC-SLS, or that have exactly 86400 seconds per UTC day in the long run,
such as Google's "leap smear".  But SRFI-19 doesn't refer to any of those,
it refers to UTC.  The true UTC has a variable number of seconds per day
*as judged by UTC clocks*: the days are not merely different lengths as
judged by TAI.

The variable number of UTC seconds per day is the source of the famous
"23:59:60" notation.  On a day with a positive leap second, the first
second of the day is centred on 00:00:00.5, the 86400th second is centred
on 23:59:59.5, and the 86401st second is centred on 23:59:60.5.  These
are 86401 distinct seconds counted by UTC, each with a distinct label.
On a day with a negative leap second, UTC only counts 86399 seconds:
the time-of-day labels never reach 23:59:59.

It is intrinsic to the definition of UTC that durations (measured in
seconds) don't match up regularly with time of day.  It's just like
the way that intervals measured in days don't match up regularly with
day of month: the way to think about a day of UTC is a lot like the way
one thinks about a month of the Gregorian calendar.  (Though there's an
important difference in that we know the lengths of Gregorian months
arbitrarily far in advance but only know UTC day lengths months in
advance.)  Wanting to avoid all that irregularity is the motivation to
use UTC-SLS and the like.

>Having said all of this, I should admit that I'm not an expert on time
>standards,

I am.

Incidentally, there's an aspect of the present bug report that's
different in the pre-1972 era.  time-difference correctly shows a
duration of exactly 86400 seconds on the UTC scale for an ordinary day
in that era, such as 1967-03-14 of which I examined the TAI duration
in bug#26632.  But it incorrectly shows the same duration for a day
with a leap.  That's the same error that it makes for post-1972 leaps,
but there's a difference in that the duration of the leap (as judged
in UTC) is non-integral, being derived from a non-integral number of
TAI seconds and also affected by the frequency offset.  For example,
the UTC duration of 1968-01-31 (also examined in bug#26632) was exactly
8639990259200/100000003 seconds (roughly 86399.900000003 s).  This runs
into trouble with SRFI-19's insistence that the nanosecond field of a
time object only contain an integer.

-zefram

bug#26164: time-difference mishandles leap seconds

[John Cowan]

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

On Mon, Nov 5, 2018 at 6:03 AM Zefram <zefram@fysh.org> wrote:

Mark H Weaver wrote:
>
> No, that's not how UTC works.


Everything Zefram says is what I was trying to say and failing.

I would only add that:

1) TAI-UTC refers to broken-down time, not to the count
of seconds since some epoch.  TAI-UTC is currently 37 seconds, which means
that at 2018-11-05T13:43:00 UTC time (approximately when I am writing this)
it is
2018-11-05T13:43:37 TAI time.

2) Posix time, unlike UTC really does label leap seconds with the same
integer as the
preceding second.


> >Having said all of this, I should admit that I'm not an expert on time
> >standards,
>
> I am.
>

He is.

-- 
John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
There is no real going back.  Though I may come to the Shire, it will
not seem the same; for I shall not be the same.  I am wounded with
knife, sting, and tooth, and a long burden.  Where shall I find rest?
                --Frodo

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

bug#26164: time-difference mishandles leap seconds

[Mark H Weaver]

Zefram <zefram@fysh.org> writes:

> Mark H Weaver wrote:
>>Having said all of this, I should admit that I'm not an expert on time
>>standards,
>
> I am.

Okay, you claim to be one, and maybe you're right, but I've also done a
great deal of research on this recently and in the past, and I'm not yet
convinced.

If you're right that there's still a problem, please post to the SRFI-19
mailing list and engage with the time experts there.  If you can
convince them to change the behavior of 'time-difference' in their
reference implementation, then I'll be glad to merge those changes into
Guile.

     Thanks,
       Mark

bug#26164: time-difference mishandles leap seconds

[Mark H Weaver]

Zefram <zefram@fysh.org> writes:

> Mark H Weaver wrote:
>>                                                       every UTC day has
>>exactly 86400 UTC seconds,
>
> No, that's not how UTC works.  There are some time scales derived from UTC
> that have exactly 86400 seconds for each UTC day, such as Markus Kuhn's
> UTC-SLS, or that have exactly 86400 seconds per UTC day in the long run,
> such as Google's "leap smear".  But SRFI-19 doesn't refer to any of those,
> it refers to UTC.

BTW, I discussed this with John Cowan at length in bug 22034, starting
at message #19:

  https://bugs.gnu.org/22034#19

In particular, I would be curious to know how you would fill in the same
table that John attempted to fill in, here:

  https://bugs.gnu.org/22034#55

What numbers would you write in the second column of those tables?

    Thanks,
      Mark