Skip Menu |

This queue is for tickets about the DateTime-Format-DateManip CPAN distribution.

Report information
The Basics
Id: 55771
Status: open
Priority: 0/
Queue: DateTime-Format-DateManip

People
Owner: Nobody in particular
Requestors: ANDK [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 0.04
Fixed in: (no value)



Subject: Failing since 2010-03-14
Since 2010-03-14 nearly all reports show failing tests: http://matrix.cpantesters.org/?dist=DateTime-Format-DateManip&maxver= (Click on "All" and sort by ID) The only PASS since then are with Date::Manip 5.5x. On that day DateTime was updated to 0.54 but I do not understand how this update relates to the failing tests. There sure are several FAIL reports also with older versions of DateTime, submitted after the 14th of March. HTH, Regards,
From: chrisb [...] debian.org
On Mon Mar 22 02:52:08 2010, ANDK wrote: Show quoted text
> The only PASS since then are with Date::Manip 5.5x.
It looks like this is actually to do with the recent changes to Date::Manip's timezone handling. Specifically, how it deals with ambiguous timezone abbreviations. The test in t/01conversions.t uses the abbreviation "EST". However according to [0], there are three different timezones all with the abbreviation "EST": EST Eastern Summer Time Australia UTC + 11 hours EST Eastern Standard Time Australia UTC + 10 hours EST Eastern Standard Time North America UTC - 5 hours It appears that the old version of Date::Manip used to pick the North American "EST", whereas the new one is choosing the Australian Eastern Summer Time. This gives a 16 hour shift between the expected value and the actual result. The following patch amends the test to use the timezone string "US/Eastern" instead, removing the ambiguity: Index: t/01conversions.t =================================================================== --- t/01conversions.t (revision 54833) +++ t/01conversions.t (working copy) @@ -10,7 +10,7 @@ my $dfdm = "DateTime::Format::DateManip"; ## Set the timezone for Date::Manip and DateTime -my $dm_tz = "EST"; +my $dm_tz = "US/Eastern"; my $dt_tz = "US/Eastern"; # Setup Date::Manip manually so we can force the TZ to beat a config @@ -21,7 +21,7 @@ my @dm_to_dt_tests = (["March 23, 2003" => DateTime->new(year => 2003, month => 3, day => 23, time_zone => $dt_tz) ], - ["March 23, 2003 12:00 EST" => + ["March 23, 2003 12:00 US/Eastern" => DateTime->new(year => 2003, month => 3, day => 23, hour => 12, time_zone => $dt_tz) ], ); [0] http://www.timeanddate.com/library/abbreviations/timezones/ -- Chris Butler <chrisb@debian.org> GnuPG Key ID: 4096R/49E3ACD3
From: chrisb [...] debian.org
On Mon Mar 29 14:14:28 2010, crispygoth wrote: Show quoted text
> On Mon Mar 22 02:52:08 2010, ANDK wrote:
> > The only PASS since then are with Date::Manip 5.5x.
> > It looks like this is actually to do with the recent changes to > Date::Manip's timezone handling. Specifically, how it deals with > ambiguous timezone abbreviations.
After a bit of discussion on the Debian bug report, we reckon that the change of behaviour in Date::Manip is the real bug. As far as we can tell, the abbreviation EST for American Eastern Standard Time is more commonly used than the Australian one, so Date::Manip should prefer the American EST instead. I've reported this against Date::Manip as CPAN bug #58159.
From: chrisb [...] debian.org
On Sat Jun 05 07:03:43 2010, crispygoth wrote: Show quoted text
> I've reported this against Date::Manip as CPAN bug #58159.
Sullivan Beck has responded to this bug: In any case,this is actually kind of a tricky problem since there are now two versions of Date::Manip that are not 100% compatible, and if the DateTime-Format-DateManip module wants their test suite to work with either one, they're going to have to add some version-specific handling in a few cases. It shouldn't be hard, and I'll be happy to work with them if they are interested. https://rt.cpan.org/Public/Bug/Display.html?id=58159#txn-789299