[tz] Leap Second Support Interval Field Request - RFC8536

Steffen Nurpmeso steffen at sdaoden.eu
Fri Dec 6 17:35:30 UTC 2019


Michael H Deckers via tz wrote in <b83f4bde-dfa1-5434-c181-3384fdf73a1b@\
googlemail.com>:
 |    On 2019-12-06, Arthur David Olson proposed
 |    a method to expose in TZif the expiration date
 |    of the leap second information:
 |
 |> One odd possibility below.
 |>
 |>      @dashdashado
 |>
 |> Zone    Etc/Leapendstat 0       -       PRE     2020 Jun 28
 |>                          0       -       POST
 |>
 |
 |    Why not produce a tzdb Zone for TAI? As if we had
 |
 |        Zone    Etc/TAI  0:00:10 -      TAI     1972 Jul  1
 |                         0:00:11 -      TAI     1973 Jan  1
 |                         ....
 |                         0:00:35 -      TAI     2015 Jul  1
 |                         0:00:36 -      TAI     2017 Jan  1
 |                         0:00:37 -      TAI     2020 Jun 28
 |                         0:00:37 -      N_A
 |
 |    After all, the Bulletins C of the IERS specify TAI as
 |    a function of UTC, just like a tzdb "timezone".

That is a great idea!  What i always missed with UTC and leap
seconds, or say, time keeping as you get it on a Unix system out
of the box, is the difference to TAI, that is, the number of leap
seconds.  You could even do calendar stuff with seconds if you had
that possibility.  At least a bit.  But anyway it would be
possible to notify the occurrence of a leap second even after it
had happened, out of the box.
Interesting.  I never thought of that possibility.  It does not
seem to fit right/ ;).

 |    Michael Deckers.
 |
 --End of <b83f4bde-dfa1-5434-c181-3384fdf73a1b at googlemail.com>

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)



More information about the tz mailing list