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