[tz] Leap Second Support Interval Field Request - RFC8536
Arthur David Olson
arthurdavidolson at gmail.com
Fri Dec 6 05:09:46 UTC 2019
One odd possibility below.
Zone Etc/Leapendstat 0 - PRE 2020 Jun 28
0 - POST
On Thu, Dec 5, 2019 at 11:34 PM Paul Eggert <eggert at 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 at iana.org and tzdist-bis at ietf.org to see whether
> anybody there cares to comment.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tz