FW: missing extension rules
dpatte at relativedata.com
Thu Sep 29 14:18:12 UTC 2011
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
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.
> -----Original Message-----
> From: Zefram [mailto:zefram at fysh.org]
> Sent: Wednesday, September 28, 2011 6:10
> To: tz at 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.
"We don't serve your type in our bar!", exclaimed the Bartender.
A faster-than-light Neutrino enters a bar.
More information about the tz