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