Skip Menu |

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

Report information
The Basics
Id: 52645
Status: rejected
Priority: 0/
Queue: DateTime-Format-ISO8601

Owner: Nobody in particular
Requestors: cmanley [...]

Bug Information
Severity: Important
Broken in: 0.06
Fixed in: (no value)


Subject: Can't parse valid strings like "2009-12-10T09:00:00.00+0100"
See subject.
Download (untitled) / with headers
text/plain 477b
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/ DateTime-Format-ISO8601-0.07_patched/lib/DateTime/Format/ --- DateTime-Format-ISO8601-0.07/lib/DateTime/Format/ 2010-01-18 07:36:55.000000000 +0100 +++ DateTime-Format-ISO8601-0.07_patched/lib/DateTime/Format/ 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' ); +} { 19850412T101530.5+0400
Download (untitled) / with headers
text/plain 641b
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 <> email list. See <> 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 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. ;)
Download (untitled) / with headers
text/plain 609b
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 says "Expressions of the difference between local time and UTC of day are a component in the representations defined in; 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.

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to