Subject: Re: [Tzdist-bis] Leap Second Support Interval Field Request - RFC8536

From: Paul Eggert <[email-masked]>
Date: Thu, 5 Dec 2019 20:34:31 -0800

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 [email-masked] and [email-masked] to see whether 
anybody there cares to comment.

---

From: Arthur David Olson <[email-masked]>
Date: Fri, 6 Dec 2019 00:09:46 -0500

One odd possibility below.

    @dashdashado

Zone    Etc/Leapendstat 0       -       PRE     2020 Jun 28
                        0       -       POST

---

From: Michael H Deckers <[email-masked]>
Date: Fri, 6 Dec 2019 11:48:47 +0000

On 2019-12-06, Arthur David Olson proposed
    a method to expose in TZif the expiration date

> Zone    Etc/Leapendstat 0       -       PRE     2020 Jun 28

    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.

---

From: Paul Eggert <[email-masked]>
Date: Fri, 6 Dec 2019 13:45:22 -0800

> Zone    Etc/Leapendstat 0       -       PRE     2020 Jun 28

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.

>                         0:00:37 -      TAI     2020 Jun 28

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.

---

From: Michael H Deckers <[email-masked]>
Date: Sat, 7 Dec 2019 01:15:26 +0000

On 2019-12-06 21:45, Paul Eggert wrote:

> 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.