[tz] RFC 8536bis

[brian.inglis at systematicsw.ab.ca]

On 2024-02-01 09:41, Michael H Deckers via tz wrote:
>     On 2024-01-31 21:23, Paul Eggert wrote:
>> That merely causes zic to accept .zi input containing four transitions per 
>> year for the foreseeable future. Input like this, for example:
>>
>>   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
>>   Zone Antarctica/Troll 0    -     -00 2005 Feb 12
>>                         0:00 Troll %s
>>
>> (This isn't in tzdata, but it could be once we can assume tzcode 2014b or later.)
>>
>> When zic sees input like this, it generates a big TZif file with explicit 
>> transitions out to the year 2407 (2005 + 402 years). The big TZif file does 
>> not have a TZ string, because no TZ string can represent all these transitions.
> 
> 
> 
>     Maybe I did not get it. 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
> 
>     If so -- why don't we just specify Rule Troll in the latter form so that
>     it correctly describes what is produced by zic? No change in zic would
>     have been required.
> 
>     Or does zic treat it 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    2406    -       Nov      7 1:00u 0:00    +00
> 
>     Where is this behavior of zic documented so that one can find out?
> 
>     More basically, I believe that 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.

Compilers can not change source code, they transform it into what they consider 
a useful form for the target; sometimes default limits are imposed, as arbitrary 
verges towards pointless; often these may be changed, depending on target 
capabilities.

If the target limit is insufficient, you may be able to extend the output to 
4kyr, 9kyr, etc. using range arguments.

It may be a limitation of the supported output formats and readers using them, 
so readers may be unable to process extended ranges.

I suspect the developer thought that as the Gregorian calendar has been 
unchanged for 400yr, projecting changes another 400yr should be adequate, as the 
calendar or rules are likely to be changed by then.

For the most frequent use of these features, Ramadan rules, unless the dates are 
predicted using astronomical software for lunar visibility at the specific 
locations involved, the dates are only approximate, and also depend on the month 
change visibility rules for each location, which may be eyeball dependent.

Suggest patches to improve the behaviour or documentation.

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry