Zefram wrote:
J. Shirley wrote:
Do not try to use named time zones (like "America/Chicago") with dates
very far in the future (thousands of years). The current
implementation ofDateTime::TimeZone?will use a huge amount of memory
calculating all the DST changes from now until the future date.
You could instead use DateTime::TimeZone::Tzfile, which does not suffer
from this problem. Just requires that you have the compiled Olson files
(which are freely available if you don't already have them).
$zone = DateTime::TimeZone::Tzfile->new(
filename => "/usr/share/zoneinfo/America/Chicago",
);
$dt = DateTime->new(
year => 30000, month => 1, day => 1,
time_zone => $zone,
);
That looks like a great place to start. If it matches the DT::TZ interface,
and shipped a default time zone database, could DT::TZ simply be replaced with
it? DT::TZ appears to be duplicating a lot of the work that's already in a
tzfile.
--
Reality is that which, when you stop believing in it, doesn't go away.
-- Phillip K. Dick
