[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