[tz] RFC 8536bis

[Paul Eggert]

On 2024-02-01 08:41, Michael H Deckers wrote:

> Are you saying that zic (after 2014b) treats 
> the input
> 
>          # Rule NAME    FROM    TO      -       IN      ON AT SAVE    
> LETTER/S
>          Rule   Troll   2005    max     -       Mar      1 1:00u 1:00    
> +01
>          Rule   Troll   2005    max     -       Mar     lastSun 1:00u 
> 2:00    +02
>          Rule   Troll   2005    max     -       Oct     lastSun 1:00u 
> 1:00    +01
>          Rule   Troll   2004    max     -       Nov      7 1:00u 0:00    
> +00
> 
>     as if it were
> 
>          # Rule NAME    FROM    TO      -       IN      ON AT SAVE    
> LETTER/S
>          Rule   Troll   2005    2407    -       Mar      1 1:00u 1:00    
> +01
>          Rule   Troll   2005    2407    -       Mar     lastSun 1:00u 
> 2:00    +02
>          Rule   Troll   2005    2407    -       Oct     lastSun 1:00u 
> 1:00    +01
>          Rule   Troll   2004    2407    -       Nov      7 1:00u 0:00    
> +00

Yes, that's it.


>     If so -- why don't we just specify Rule Troll in the latter form so 
> that
>     it correctly describes what is produced by zic?
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.

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.


>     Where is this behavior of zic documented so that one can find out?

In zic.8; look for -v.


>     a compiler that tacitly changes the
>     source code in this manner if it cannot correctly compile the
>     original source is detrimental to the production of reliable software.

Try -v and see what you think.