FW: missing extension rules

[Zefram]

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