Bug #52645 for DateTime-Format-ISO8601: Can't parse valid strings like "2009-12-10T09:00:00.00+0100"

Thu Dec 10 04:20:31 2009 cmanley [...] cpan.org - Ticket created

Subject:

Can't parse valid strings like "2009-12-10T09:00:00.00+0100"

See subject.

Mon Jul 04 15:13:45 2011 domm [...] cpan.org - Correspondence added

The attached patch (code & test) fixes this issue. If you need the patch in some other format (or have a git repo for me to clone), just drop me a line... hm, now that I take a close look at the subject line, I'm not sure it fixes that issue, but it does fix perl -MDateTime::Format::ISO8601 -E 'say DateTime::Format::ISO8601->parse_datetime("2011-07-04T20:50:23+0200")' which currently does not work (but "2011-07-04T20:50:23+02:00" works, note the ":" in the timezone)

Subject:

datetime_format_iso8609_rt52645_fix.patch

diff -r -u DateTime-Format-ISO8601-0.07/lib/DateTime/Format/ISO8601.pm DateTime-Format-ISO8601-0.07_patched/lib/DateTime/Format/ISO8601.pm --- DateTime-Format-ISO8601-0.07/lib/DateTime/Format/ISO8601.pm 2010-01-18 07:36:55.000000000 +0100 +++ DateTime-Format-ISO8601-0.07_patched/lib/DateTime/Format/ISO8601.pm 2011-07-04 21:01:07.265826915 +0200 @@ -669,7 +669,7 @@ { #YYYYMMDDThhmmss[+-]hhmm 19850412T101530+0400 #YYYY-MM-DDThh:mm:ss[+-]hh:mm 1985-04-12T10:15:30+04:00 - length => [ qw( 20 25 ) ], + length => [ qw( 20 24 25 ) ], regex => qr/^ (\d{4}) -?? (\d\d) -?? (\d\d) T (\d\d) :?? (\d\d) :?? (\d\d) ([+-] \d\d :?? \d\d) $/x, params => [ qw( year month day hour minute second time_zone ) ], diff -r -u DateTime-Format-ISO8601-0.07/t/02_examples.t DateTime-Format-ISO8601-0.07_patched/t/02_examples.t --- DateTime-Format-ISO8601-0.07/t/02_examples.t 2010-01-18 07:36:55.000000000 +0100 +++ DateTime-Format-ISO8601-0.07_patched/t/02_examples.t 2011-07-04 21:01:33.365791500 +0200 @@ -9,7 +9,7 @@ use lib qw( ./lib ); -use Test::More tests => 174; +use Test::More tests => 176; use DateTime::Format::ISO8601; @@ -610,6 +610,12 @@ is( $dt->iso8601, '1985-04-12T10:15:30' ); is( $dt->time_zone->name, '+0400' ); } +{ + #YYYY-MM-DDThh:mm:ss+hh:mm 1985-04-12T10:15:30+0400 + my $dt = $iso8601->parse_datetime( '1985-04-12T10:15:30+0400' ); + is( $dt->iso8601, '1985-04-12T10:15:30' ); + is( $dt->time_zone->name, '+0400' ); +} { #YYYYMMDDThhmmss.ss+hhmm 19850412T101530.5+0400

Mon Jul 04 15:13:46 2011 The RT System itself - Status changed from 'new' to 'open'

Sun Feb 12 01:02:34 2012 jhoblitt [...] cpan.org - Correspondence added

On Thu Dec 10 04:20:31 2009, CMANLEY wrote: Show quoted text

> See subject.

I apologise for taking so long to address this ticket. I had not been using this bug tracker for the modules I maintain. Per the POD attached to the module: SUPPORT Support for this module is provided via the <datetime@perl.org> email list. See <http://lists.perl.org/> for more details. It's taken me some time to review to standard again to determine if this is a bug or not. I think that per section 4.2.2.4 this is allowed althouh none of the section 4.3.2 examples use fractional seconds. I will get a corrected release our soon, just a few years late. ;)

Sun Feb 12 01:50:51 2012 jhoblitt [...] cpan.org - Correspondence added

After further consideration, I believe both 2009-12-10T09:00:00.00+0100 and 2011-07-04T20:50:23+0200 to be invalid formats for the same reason. Section 4.2.5.1 says "Expressions of the difference between local time and UTC of day are a component in the representations defined in 4.2.5.2; they shall not be used as self-standing expressions.". Which means the UTC offset is considered part of the time format so you get to use the extended formation (the ':') or not but you can't mix and match the two. Unfortunately, the 0.07 release accepts 2011-07-04T20:50:23+0200. 0.08 should appear on CPAN shortly.

Sun Feb 12 01:50:53 2012 jhoblitt [...] cpan.org - Status changed from 'open' to 'rejected'