[tz] RFC 8536bis
Michael H Deckers
michael.h.deckers at googlemail.com
Fri Feb 2 16:10:55 UTC 2024
On 2024-02-01 18:36, Paul Eggert wrote:
> As I recall, the goal was to have the data be as close as possible to
> what we want to predict, and to have zic implement that as best it
> can, which is not perfectly due to the limitations of the TZif format.
Agreed. And currently, what we want to predict for the
future of Rule Troll is commented out, in favor of a
description of what currently is done. I do not see a
reason why this same scheme could not be applied with
'max' (our prediction) replaced by '2407' (as best as
zic can do with the code of 2014b).
>
>
> It's similar to how zic implements this:
>
> Zone Europe/Amsterdam 0:19:32.13 - LMT
>
> It drops the ".13". If you use zic -v it issues a warning.
>
There is a decisive difference: zic(8) explicitly
says that
..zic rounds times to the nearest integer second
(breaking ties to the even integer),...
while I have not found an indication in zic(8) when
the "400 year hack" applies.
> Try -v and see what you think.
I am sorry but I would not use a C compiler that
successfully compiles a translation unit containing
int A[ SIZE_MAX ] ;
together with a warning to the effect that array A
has been shortened to 402 elements. Apparently I am
too picky.
Michael Deckers.
More information about the tz
mailing list