[Melbourne-pm] DateTime::TimeZone breaking under PAR?
daniel at rimspace.net
Mon Dec 22 00:36:28 PST 2008
"Toby Wintermute" <tjc at wintrmute.net> writes:
> I encountered an odd problem with DateTime::TimeZone today.
> When using it via a PAR archive, it refused to determine the local timezone.
> (This was on a Debian Etch fresh install, albeit with upgraded PAR
> libraries, since the normal Etch ones are quite broken, and then
> confirmed on an Ubuntu Hardy setup as well.)
DateTime::TimeZone::Local requires a set of additional classes to
operate, which are loaded at runtime through 'eval "use $class"', which
PAR will probably not detect — certainly not without running, and not
completely in any case.
You want to include all the classes under the DateTime::TimeZone
namespace, such as DateTime::TimeZone::Australia::Melbourne.
(For me it blows up on DateTime::TimeZone::Local::Unix, which is
doubtless a symptom of the same issue.)
> The test script that fails:
> use strict;
> use warnings;
> use DateTime;
> use DateTime::TimeZone;
> my $tz = DateTime::TimeZone->new( name => 'local' );
> print "Success!\n";
> Create the PAR with:
> pp -o datetime.par -M DateTime::Locale::en timetest.pl
> (That's on Etch.. If I'm on Hardy I need an extra: -M
> DateTime::TimeZone::Local::Unix )
> Then execute it:
> parl datetime.par timetest.pl
> I get "Cannot determine local time zone", rather than "Success!", on
> both Etch and Hardy.
> DateTime versions:
> Etch - 0.35
> Hardy - 0.42 and then 0.4501
> DateTime::TimeZone versions:
> Etch - 0.42
> Hardy - 0.7701 and then 0.8301
> Any thoughts if I'm Doing It Wrong, before I submit to RT?
> Melbourne-pm mailing list
> Melbourne-pm at pm.org
More information about the Melbourne-pm