[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