I'm forwarding this message from Zefram; since sending it, Zefram has subscribed to the time zone mailing list. --ado -----Original Message----- From: Zefram [mailto:zefram@fysh.org] Sent: Wednesday, September 28, 2011 6:10 To: tz@lecserver.nci.nih.gov Subject: missing extension rules I've found a problem with the tzfiles for Africa/Cairo and America/Argentina/San_Luis. They both show a last known transition in the recent past, and surprisingly lack a POSIX-TZ-format rule for extending the zone into the future. My tzfile parser treats a zone with no extension rule as being undefined for any time following the last explicit transition, so for these two zones it reckons the zone is undefined for the present. In the source files they're each currently configured to observe a set of DST rules, and the ruleset has no transitions configured for the future. So for the present and foreseeable future, the zone is on a constant offset with no DST transitions. The tzfile reflects that by showing no transitions from the present up to 2038 (where zic always fills in a complete set of expected transitions). It should be trivial to also reflect that foreseen behaviour in a POSIX-TZ string that just gives a fixed offset and no DST rule. For example, Africa/Cairo should clearly have "EET-2". I could have a go at a zic patch to fix this, if the regular zic hackers would like to work that way. For America/Argentina/San_Luis there's an extra wrinkle: the last known transition is a transition *to* DST. Its fixed-offset foreseeable behaviour therefore has a fixed is_dst=1, which is moderately silly. It's arguable that in this case it would be incorrect to give a "WARST3" extension rule, because that doesn't accurately express the DST status. Since that DST transition was in 2009, it's also a good bet that they haven't stayed continuously on DST since then, of course. -zefram
On our own inhouse tzfile compiler, we see no issues with Cairo or San_Luis and they currently show EET and WARST respectively, with no planned future traansitions. Cairo did abandon summer time earlier this year. But it is true that San_Luis is currently marked as summer time with no planned transitions, which is indeed odd. Which tzfile parser are you using? On 2011-09-29 9:59, Olson, Arthur David (NIH/NCI) [E] wrote:
I'm forwarding this message from Zefram; since sending it, Zefram has subscribed to the time zone mailing list.
--ado
-----Original Message----- From: Zefram [mailto:zefram@fysh.org] Sent: Wednesday, September 28, 2011 6:10 To: tz@lecserver.nci.nih.gov Subject: missing extension rules
I've found a problem with the tzfiles for Africa/Cairo and America/Argentina/San_Luis. They both show a last known transition in the recent past, and surprisingly lack a POSIX-TZ-format rule for extending the zone into the future. My tzfile parser treats a zone with no extension rule as being undefined for any time following the last explicit transition, so for these two zones it reckons the zone is undefined for the present.
In the source files they're each currently configured to observe a set of DST rules, and the ruleset has no transitions configured for the future. So for the present and foreseeable future, the zone is on a constant offset with no DST transitions. The tzfile reflects that by showing no transitions from the present up to 2038 (where zic always fills in a complete set of expected transitions). It should be trivial to also reflect that foreseen behaviour in a POSIX-TZ string that just gives a fixed offset and no DST rule. For example, Africa/Cairo should clearly have "EET-2".
I could have a go at a zic patch to fix this, if the regular zic hackers would like to work that way.
For America/Argentina/San_Luis there's an extra wrinkle: the last known transition is a transition *to* DST. Its fixed-offset foreseeable behaviour therefore has a fixed is_dst=1, which is moderately silly. It's arguable that in this case it would be incorrect to give a "WARST3" extension rule, because that doesn't accurately express the DST status. Since that DST transition was in 2009, it's also a good bet that they haven't stayed continuously on DST since then, of course.
-zefram
-- "We don't serve your type in our bar!", exclaimed the Bartender. A faster-than-light Neutrino enters a bar.
David Patte wrote:
Which tzfile parser are you using?
My Perl module DateTime::TimeZone::Tzfile. The relevant part of its behaviour is that it's conservative about future timezone behaviour (when parsing a v2 tzfile). If there's a POSIX-TZ extension rule then all is well. If not, then it interprets the tzfile as providing no information about the timezone for times following the last observance listed. More precisely, since the last observance isn't labelled with an end time, it perceives no information for times following the last transition, at the beginning of the last listed observance. This works fine for zones that correctly lack an extension rule. For example, the current Chilean rule can't be expressed in POSIX-TZ form. America/Santiago therefore has no extension rule, but to make up for it zic puts 400 years of explicit transitions in the file, with the last listed transition on 2412-10-14. (It happens to be a transition *to* DST.) DT:TZ:Tzfile handles current and near future Santiago times just fine, but the balks if it gets a date later than 2412-10-14. With Africa/Cairo, zic mistakenly thinks it can't express the rule in POSIX-TZ form. Presumably it attempts to make up for this by putting 400 years of transitions into the file, but that ends up being no actual transitions, so the file ends up with its last transition being on 2010-09-30. DT:TZ:Tzfile can only suppose that the zone's behaviour following 2010-09-30 is not represented in the file, so it bombs out on current times. It would be conceivable for DT:TZ:Tzfile to have a built-in expectation that a tzfile lacking an extension rule is nevertheless guaranteed to be complete up to 2412, or something like that. But that's not a documented feature of the tzfile format, it's just current behaviour of zic, and the 2412 isn't actually a constant. I think the only year I could conceivably build in there would be 2038, because zic always provides a complete listing up to 2038, but this would be saving up a Y2038 problem. -zefram
I've found that zic normally copes correctly with zones that are configured to observe DST rules and the ruleset has no future transitions. The problem with Africa/Cairo is that when looking for the last rule zic gets confused by there being two transitions in a single month. It fails to distinguish between their dates, and incorrectly ends up thinking that the transition to DST was latest. The attached patch fixes this bug. Africa/Cairo is the only tzfile affected by the change, and the only change to it is to fill the POSIX-TZ field. I also pointed out America/Argentina/San_Luis. It turns out that zic is deliberately declining to fill the POSIX-TZ field, because of the DSTness of the last observation. This is the same reason why it left that field empty in Africa/Cairo, once it had made the mistake about which observation came last. I have a plan for improving this situation, which I'll address in a separate patch. -zefram
I wrote:
I also pointed out America/Argentina/San_Luis. It turns out that zic is deliberately declining to fill the POSIX-TZ field, because of the DSTness of the last observation. This is the same reason why it left that field empty in Africa/Cairo, once it had made the mistake about which observation came last. I have a plan for improving this situation, which I'll address in a separate patch.
Attached patch changes this behaviour. In the case where 400 years of explicit observations are being generated due to inability to express the extension rule in the POSIX-TZ field, if there are actually no observations being generated then a redundant observation is added on the end. This provides an explicit endpoint for the explicit observations. Code that claims no knowledge after the final transition, like my Perl module, are OK for 400 years. Code that tries to repeat the last 400 years has some clue as to which 400 years to repeat. I extended the existing exception for the case where the source lists explicit transitions up to 2037. The code recognises this as indicating that the behaviour after 2037 is not expressed in the zone source, rather than being an explicit list of transitions that actually ends in 2037. The code declines to fill the POSIX-TZ field in this case. I made it also decline to add the redundant observation 400 years later. When this is applied on top of my previous patch, the only tzfile affected by this change is America/Argentina/San_Luis. I reviewed all the tzfiles that have their POSIX-TZ field empty. I believe all the remaining ones have a good excuse. Specifically (excluding links): America/Santiago Antarctica/Palmer Pacific/Easter "Chile" rules, transitions on Sun>=9, can't be expressed in POSIX-TZ America/Godthab "EU" rules, transitions at 01:00 UT which would be 22:00 or 23:00 of previous day in local time, can't be expresssed in POSIX-TZ Asia/Amman "Jordan" rules, transition at 24:00 local time, can't be expressed in POSIX-TZ Asia/Jerusalem "Zion" rules, real rule inexpressible in source, transitions listed explicitly up to 2037 Asia/Tehran "Iran" rules, real rule inexpressible in source, transitions listed explicitly up to 2037 -zefram
participants (3)
-
David Patte -
Olson, Arthur David (NIH/NCI) [E] -
Zefram