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

[Mark H Weaver]

John Cowan <address@hidden> writes:

> On Sat, Oct 20, 2018 at 5:43 PM Mark H Weaver <address@hidden> 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