Re: [tz] Leap Second Support Interval Field Request - RFC8536
On 12/4/19 1:04 PM, Michael Veth wrote:
The NIST leapsecond bulletin includes an expiration time which serves to indicate the maximum validity interval for use of UTC time. In order to safely use UTC timestamps, the user needs to be aware of this maximum validity time or they could be unknowingly introducing timing errors.
I was not able to find this field in the TZif (Feb 19) ICD. Would it be possible to add a field to the TZdb that would represent this expiration time?
The TZif file format does provide for truncated files (see Internet RFC 8536 section 5.1), and one can generate files truncated to the current UTC expiration time (2020-06-28 00:00:00 UTC) with a command like this: zic -r /@1593302427 -L leapseconds tzdata.zi However, it's awkward that one must count the number of seconds since 1970-01-01 00:00:00 UTC (including leap seconds) by hand to get the numeric timestamp (1593302427 in this case) to pass to zic. We could add support to zic to do this sort of thing in a more-natural way. A downside of the abovementioned approach is that it generates a TZif file that omits all DST and time zone transitions after the UTC expiration time. We could change the TZif format to represent UTC expiration time separately from the truncation time. One possibility would be to append a leap-second record with an "occur" value equal to the expiration time and a "corr" value equal to the previous record's "corr" value. Strictly speaking this would violate RFC 8536 section 3.2 "leap-second records" - though I doubt whether many clients would care - and so I suppose we'd need to increment the TZif format version number from 3 to 4. On the other hand, any files generated by this method would continue to be "incorrect" in that they'd continue to predict timestamps past the maximum leap second validity, so perhaps it wouldn't be worth going to all this work to generate "incorrect" files. I'll cc this to tz@iana.org and tzdist-bis@ietf.org to see whether anybody there cares to comment.
One odd possibility below. @dashdashado Zone Etc/Leapendstat 0 - PRE 2020 Jun 28 0 - POST On Thu, Dec 5, 2019 at 11:34 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
On 12/4/19 1:04 PM, Michael Veth wrote:
The NIST leapsecond bulletin includes an expiration time which serves to indicate the maximum validity interval for use of UTC time. In order to safely use UTC timestamps, the user needs to be aware of this maximum validity time or they could be unknowingly introducing timing errors.
I was not able to find this field in the TZif (Feb 19) ICD. Would it be possible to add a field to the TZdb that would represent this expiration time?
The TZif file format does provide for truncated files (see Internet RFC 8536 section 5.1), and one can generate files truncated to the current UTC expiration time (2020-06-28 00:00:00 UTC) with a command like this:
zic -r /@1593302427 -L leapseconds tzdata.zi
However, it's awkward that one must count the number of seconds since 1970-01-01 00:00:00 UTC (including leap seconds) by hand to get the numeric timestamp (1593302427 in this case) to pass to zic. We could add support to zic to do this sort of thing in a more-natural way.
A downside of the abovementioned approach is that it generates a TZif file that omits all DST and time zone transitions after the UTC expiration time. We could change the TZif format to represent UTC expiration time separately from the truncation time. One possibility would be to append a leap-second record with an "occur" value equal to the expiration time and a "corr" value equal to the previous record's "corr" value. Strictly speaking this would violate RFC 8536 section 3.2 "leap-second records" - though I doubt whether many clients would care - and so I suppose we'd need to increment the TZif format version number from 3 to 4. On the other hand, any files generated by this method would continue to be "incorrect" in that they'd continue to predict timestamps past the maximum leap second validity, so perhaps it wouldn't be worth going to all this work to generate "incorrect" files.
I'll cc this to tz@iana.org and tzdist-bis@ietf.org to see whether anybody there cares to comment.
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". Michael Deckers.
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@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)
On 12/5/19 9:09 PM, Arthur David Olson wrote:
Zone Etc/Leapendstat 0 - PRE 2020 Jun 28 0 - POST
Although that would let someone determine leap second validity by examining a different file (or issuing another TZDIST request), Michael Veth was asking for a way to determine leap second validity by examining the same TZif file that contains the leap-second records. On 12/6/19 3:48 AM, Michael H Deckers wrote:
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
This won't have the desired effect. For example, it would cause the Etc/TAI clock's adjacent ticks to be 1972-06-30 23:59:59 and 1972-07-01 00:00:01, whereas the adjacent ticks should be 1972-06-30 23:59:60 and 1972-07-01 00:00:00. Also, when compiling the Etc/TAI zone with -L leapseconds, the resulting TZif file would have incorrect transitions because each leap second would be applied twice.
On 2019-12-06 21:45, Paul Eggert wrote:
This won't have the desired effect. For example, it would cause the Etc/TAI clock's adjacent ticks to be 1972-06-30 23:59:59 and 1972-07-01 00:00:01, whereas the adjacent ticks should be 1972-06-30 23:59:60 and 1972-07-01 00:00:00. Also, when compiling the Etc/TAI zone with -L leapseconds, the resulting TZif file would have incorrect transitions because each leap second would be applied twice.
Oops -- I should not have omitted the time of day of the switches from the Zone lines -- sorry for the confusion. The complete lines must have a time of day, of course: Zone Etc/TAI 0:00:10 - TAI 1972 Jul 1 0:00:00u 0:00:11 - TAI 1973 Jan 1 0:00:00u .... 0:00:35 - TAI 2015 Jul 1 0:00:00u 0:00:36 - TAI 2017 Jan 1 0:00:00u 0:00:37 - TAI 2020 Jun 28 0:00:00u 0:00:37 - N_A So the "adjacent ticks" you mention are in fact the TAI values 1972-07-01T00:00:09 for UTC = 1972-06-30T23:59:59Z and 1972-07-01T00:00:11 for UTC = 1972-07-01T00:00:00Z. Of course, these ticks of TAI are not adjacent: the TAI value 1972-07-01T00:00:10 in between belongs to the leap second UTC = 1972-06-30T23:59:60Z. The Zone lines for right/Etc/TAI would give TAI as a function of TAI - 10 s, so they would get the constant STDOFF value 0:00:10. (And, yes, in this case the STDOFF value after 2020-06-28 is known.) That TAI can be considered as a tzdb "timezone" is an observation by Steve Allen, if I remember correctly. Michael Deckers.
On 12/5/19 8:34 PM, I wrote:
The TZif file format does provide for truncated files (see Internet RFC 8536 section 5.1), and one can generate files truncated to the current UTC expiration time (2020-06-28 00:00:00 UTC) with a command like this:
zic -r /@1593302427 -L leapseconds tzdata.zi
However, it's awkward that one must count the number of seconds since 1970-01-01 00:00:00 UTC (including leap seconds) by hand to get the numeric timestamp (1593302427 in this case) to pass to zic. We could add support to zic to do this sort of thing in a more-natural way.
When I looked into this issue, I found a significant bug tzdb's client code: when a TZif file has leap seconds, localtime mishandles daylight-saving transitions after the file's last transition time (which is typically in the year 2037). Today I proposed a fix for this tzcode bug: https://mm.icann.org/pipermail/tz/2020-January/028792.html However, similar bugs occur in other clients, such as the GNU C Library. Although I plan to file a bug report against glibc, I imagine it'll take some time to propagate fixes into this and other libraries. As luck would have it, one workaround for the bug is to truncate TZif files along the lines suggested above, as this "fixes" old clients by removing problematic combinations of leap seconds and DST transitions from TZif files. So I implemented the above-quoted suggestion in a patch I proposed today: https://mm.icann.org/pipermail/tz/2020-January/028793.html This patch causes zic to truncate the end of an output TZif file containing leap seconds, using the leapseconds file's expiration date. The truncation is as per Internet RFC 8536 section 5.1. Although it will take some time for these patches to propagate to operating system distributions and TZDIST servers, the patches should provide a way to move forward and with luck the Y2038 leap second bug should be mostly fixed before the year 2038 rolls around. Plus, TZDIST clients should be able to determine the leap second expiration date by examining the truncated TZif files. None of these changes should affect the typical case of TZif files that omit leap seconds.
participants (4)
-
Arthur David Olson -
Michael H Deckers -
Paul Eggert -
Steffen Nurpmeso