[tz] 回复: 回复: zoneinfo generating issues
eggert at cs.ucla.edu
Sun Mar 7 02:07:41 UTC 2021
On 3/6/21 8:44 AM, Ian Abbott wrote:
> I've just realized that it is normal (as per the zic man page, I think)
> for the "right" (a.k.a. "leap") zone files to be truncated at the expiry
> time of the leapseconds file (although the files installed by Debian zic
> seem to continue beyond the expiry time). I must admit I wasn't
> expecting that. I thought the output would continue as though there
> would be no changes to the leap seconds in the future.
Yes, thanks, you've put the finger on the problem.
This issue arose due to two changes published in tzdb 2020a. The first
change fixed a bug in localtime.c, which mishandled leap seconds
after the last explicit transition in a TZif file. The second change
truncated files built with -L to when the leap-second table expires; one
objective was to work around problems with existing clients with the
For clients using TZif files with leap second support, we have three
A. Fix and/or work around the longstanding localtime.c bug.
B. Clients should be able to deduce when the leap second table expires.
C. Clients should be able to predict timestamps after the expiration
date more accurately than just "assume the latest-known UTC offset".
The second change supported (A) and (B), but broke (C).
Given the problems you described, I installed the attached patch, which
omits the truncation introduced in tzdb 2020a. This fixes (C), but
breaks both (A) and (B). I'll try to think of a better way to support
(A) and (B).
None of these changes should affect behavior with ordinary TZif files.
Only files with leap seconds are affected.
 Fix leap second bug after last explicit transition. Tue Jan 14
18:15:30 2020 -0800.
 Add support for Expires lines to zic. Tue Jan 14 18:15:30 2020
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2314 bytes
Desc: not available
More information about the tz