[tz] 回复: 回复: zoneinfo generating issues

[Tim Parenti]

On Sat, 6 Mar 2021 at 11:45, Ian Abbott via tz <tz at iana.org> 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).


>From zic.8:
"zic outputs this expiration timestamp by truncating the end of the output
file to the timestamp."

Truncation would certainly explain the behavior that is being seen here:
In 2020d, the expiry of the leapseconds file was 2021-06-28, so the far
future timestamps tested would be interpreted as though they retain the
local offsets in effect in June: -09, -08, -04, -09.
In 2021a, the expiry of the leapseconds file is 2021-12-28, so the same
timestamps would be interpreted according to December offsets: -10, -09,
-03, -10.


> 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.


I agree.  For posix/"non-leap" files, faced with a future that is unknown,
we do generally continue DST rules into the future, under the assumption
that that is more likely to be "less wrong".  Truncating the file in this
way ensures any region that uses DST will have its far future timestamps be
(a) incorrect for roughly half of the year and (b) inconsistently so, since
sometimes you'll get the June offset and sometimes you'll get the December
offset.  That seems "more wrong".

--
Tim Parenti
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20210306/64b17ba8/attachment.html>