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