<div dir="ltr"><div><span style="font-family:monospace">One odd possibility below.</span></div><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace">    @dashdashado</span></div><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace">Zone    Etc/Leapendstat 0       -       PRE     2020 Jun 28<br>                        0       -       POST</span><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 5, 2019 at 11:34 PM Paul Eggert <<a href="mailto:eggert@cs.ucla.edu">eggert@cs.ucla.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 12/4/19 1:04 PM, Michael Veth wrote:<br>
<br>
> The NIST leapsecond bulletin includes an expiration time which serves to <br>
> indicate the maximum validity interval for use of UTC time.  In order to <br>
> safely use UTC timestamps, the user needs to be aware of this maximum <br>
> validity time or they could be unknowingly introducing timing errors.<br>
> <br>
> I was not able to find this field in the TZif (Feb 19) ICD.  Would it be <br>
> possible to add a field to the TZdb that would represent this expiration <br>
> time?<br>
<br>
The TZif file format does provide for truncated files (see Internet RFC <br>
8536 section 5.1), and one can generate files truncated to the current <br>
UTC expiration time (2020-06-28 00:00:00 UTC) with a command like this:<br>
<br>
zic -r /@1593302427 -L leapseconds tzdata.zi<br>
<br>
However, it's awkward that one must count the number of seconds since <br>
1970-01-01 00:00:00 UTC (including leap seconds) by hand to get the <br>
numeric timestamp (1593302427 in this case) to pass to zic. We could add <br>
support to zic to do this sort of thing in a more-natural way.<br>
<br>
A downside of the abovementioned approach is that it generates a TZif <br>
file that omits all DST and time zone transitions after the UTC <br>
expiration time. We could change the TZif format to represent UTC <br>
expiration time separately from the truncation time. One possibility <br>
would be to append a leap-second record with an "occur" value equal to <br>
the expiration time and a "corr" value equal to the previous record's <br>
"corr" value. Strictly speaking this would violate RFC 8536 section 3.2 <br>
"leap-second records" - though I doubt whether many clients would care - <br>
and so I suppose we'd need to increment the TZif format version number <br>
from 3 to 4. On the other hand, any files generated by this method would <br>
continue to be "incorrect" in that they'd continue to predict timestamps <br>
past the maximum leap second validity, so perhaps it wouldn't be worth <br>
going to all this work to generate "incorrect" files.<br>
<br>
I'll cc this to <a href="mailto:tz@iana.org" target="_blank">tz@iana.org</a> and <a href="mailto:tzdist-bis@ietf.org" target="_blank">tzdist-bis@ietf.org</a> to see whether <br>
anybody there cares to comment.<br>
</blockquote></div>