I've finally got around to implemeting the strategy we discussed last
year for timezone data. I have uploaded three new modules to CPAN:
Time::OlsonTZ::Download
Knows how to download the Olson database source (from
elsie) and process it into useful tzfiles. Mainly for
my internal use, definitely not for end users.
Time::OlsonTZ::Data
Latest version of the Olson database, packaged up for
CPAN. Provides 64-bit tzfiles and metadata. Useful if
you've got your own tzfile reader. Goes nicely with
DateTime::TimeZone::Tzfile (my tzfile reader, already
on CPAN).
DateTime::TimeZone::Olson
Brings together Time::OlsonTZ::Data
and DateTime::TimeZone::Tzfile to provide
DateTime::TimeZone-style objects representing the Olson
timezones. A convenient end-user interface.
Please try out your DateTime-using code with DateTime::TimeZone::Olson.
I'd like to know if the objects that it supplies are incompatible with
your code that previously used DateTime::TimeZone. It doesn't provide
all of the methods that the Olson zones of DT:TZ provide: I haven't
attempted to replicate what I view as internal interfaces. Please also
look at performance issues. DT:TZ:O does fix DT:TZ's performance
problem with far-future dates, and I'd be interested to see how the
common case compares.
For trial purposes, you'll want to change
$dt = DateTime->new(..., time_zone => "America/New_York");
into
use DateTime::TimeZone::Olson qw(olson_tz);
$dt = DateTime->new(..., time_zone => olson_tz("America/New_York"));
This will, of course, only work for timezones that are actually in the
Olson database. Fixed-offset timezones such as "+01:00", and special
cases such as "floating" and "local", won't be handled by olson_tz.
I've made an interface to the Olson database, not a drop-in replacement
for DT:TZ.
If people like DT:TZ:O, we'll then look at changing DT:TZ to use it for
the Olson zones. DT:TZ would of course retain its existing special cases.
-zefram
