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