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

[Paul Eggert <[e-mail]>]

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.