In 2014b, the new tzdb timezone for Antarctica/Troll required regular switches among three offsets for the foreseeable future. This led to an extension of the TZif format so that the footer could contain two TZ strings (or so I thought); the timezone Antarctica/Troll, hwever, was modified so as to not yet require the new TZif feature. Now it appears that the latest specification "RFC 8536bis" of the TZif format does not allow for two TZ strings in the footer (or at least I did not detect it). Does that mean that the feature "two TZ strings" in a TZif file is further postponed, or is it dropped for good? Michael Deckers.
On 2024-01-31 07:36, Michael H Deckers via tz wrote:
In 2014b, the new tzdb timezone for Antarctica/Troll required regular switches among three offsets for the foreseeable future. This led to an extension of the TZif format so that the footer could contain two TZ strings (or so I thought);
There's no such feature in tzcode. I don't recall such a feature being discussed - could you point us at any thread in the archive? What I do recall is a long thread about leap second expiration, and that tzcode conforms to RFC 8536bis as far as I know.
On 2024-01-31 18:25, Paul Eggert wrote about 4 transition per year in the foreseeable future:
There's no such feature in tzcode. I don't recall such a feature being discussed - could you point us at any thread in the archive?
From NEWS for release 2014b: Changes affecting code 'zic' and 'localtime' no longer reject locations needing four transitions per year for the foreseeable future. (Thanks to Andrew Main (Zefram).) Changes affecting near-future time stamps New entry for Troll station, Antarctica. (Thanks to Paul-Inge Flakstad and Bengt-Inge Larsson.) This is currently an approximation; a better version will require the zic and localtime fixes mentioned below, and the plan is to wait for a while until at least the zic fixes propagate. From Antarctica/Troll in 2023d; # The CET-switching Troll rules require zic from tz 2014b or later, so as # suggested by Bengt-Inge Larsson comment them out for now, and approximate # with only UTC and CEST. Uncomment them when 2014b is more prevalent. Michael Deckers.
On 1/31/24 11:39, Michael H Deckers wrote:
There's no such feature in tzcode. I don't recall such a feature being discussed - could you point us at any thread in the archive?
From NEWS for release 2014b:
Changes affecting code
'zic' and 'localtime' no longer reject locations needing four transitions per year for the foreseeable future. (Thanks to Andrew Main (Zefram).)
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. Previous to 2014b, zic would reject this .zi input; and pre-2014 localtime would not always work on the big TZif files that 2014b-or-later zic generates with this .zi input. Although it might be nice for some future RFC 8536 edition to handle Troll, and for tzcode to support it, that's not in the current draft.
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.
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
On 2024-02-01 17:35, brian.inglis--- via tz wrote:
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.
I rather think that the 400 years are enough to derive the transitions throughout the indefinite future by a simple lookup in TZif data: for years 2408..2807, use the transitions of years 2008..2407, ie, 400 years earlier, etc. If localtime() etc would do that, then they would implement the Rules as originally written.
Suggest patches to improve the behaviour or documentation.
I actually tried to do that: explicitly write the Rules with 2407 instead of max, so as to make it explicit that the Rules only apply for 402 years. Michael Deckers.
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.
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.
On 2/2/24 08:10, Michael H Deckers wrote:
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.
I was thinking of this part of zic(8): -v Be more verbose, and complain about the following situations: ... The output file does not contain all the information about the long-term future of a timezone, because the future cannot be summarized as an extended POSIX TZ string.
I would not use a C compiler that successfully compiles a translation unit containing
int A[ SIZE_MAX ] ;
They're not quite the same situation. Still, that's a valid point. Perhaps zic should not try to compile unrepresentable Zone entries like these (i.e., go back to something like its behavior in tzcode 2014a and earlier), and we should remove any suggestion in the 'antarctica' comments that zic can compile the commented-out lines.
participants (3)
-
brian.inglis＠systematicsw.ab.ca -
Michael H Deckers -
Paul Eggert