Olson timezones via tzfiles
Zefram
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
Jon Bjornstad
in the DateTime suite of modules and have
come up with a few questions that are not well answered
in the FAQ so I post them here...
Question #1:
I'm confused by these methods in DateTime::Duration:
delta_days
days
in_units('days')
How are they different? When would one use each of them?
'delta_days' is apparently just the value you gave
for 'days' when constructing the object.
From its simple name, 'days' _looks_ like it is just
the 'days' value you passed to the constructor but is
actually something quite different.
in_units('days') again seems to just return
the days value you passed to the constructor.
But no... it also adds in 7*weeks.
my $dur = DateTime::Duration->new(
years => 3,
weeks => 4,
months => 1,
days => 23,
minutes => 24,
);
print $dur->delta_days(), "\n";
print $dur->days(), "\n";
print $dur->in_units('days'), "\n";
This prints
51
2
51
and so delta_days() is not just the value you passed, either.
I'm confused. When would one use these methods?
What practical problems would use each of them?
Question #2:
use DateTime::Event::Recurrence;
# Second Tuesday of every month:
#
my $set = DateTime::Event::Recurrence->monthly(
weeks => 2,
days => 2
);
my $it = $set->iterator(start => DateTime->now());
for (1 .. 10) {
my $dt = $it->next();
print "$dt\n";
}
2010-09-14T00:00:00
2010-10-12T00:00:00
2010-11-09T00:00:00
2010-12-14T00:00:00
2011-01-11T00:00:00
2011-02-15T00:00:00
2011-03-15T00:00:00
2011-04-12T00:00:00
2011-05-10T00:00:00
2011-06-14T00:00:00
This correctly prints the remaining second Tuesdays for 2010
but in 2011 it includes Feb 15th which is the 3rd Tuesday.
What's up with that?