[tz] Leap Second Support Interval Field Request - RFC8536
Paul Eggert
eggert at cs.ucla.edu
Wed Jan 15 02:51:48 UTC 2020
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.
More information about the tz
mailing list