[tz] Leap Second Support Interval Field Request - RFC8536

[Paul Eggert]

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 at iana.org and tzdist-bis at ietf.org to see whether 
anybody there cares to comment.