Skip Menu |
 

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

Report information
The Basics
Id: 108082
Status: open
Priority: 0/
Queue: DateTime-Format-ISO8601

People
Owner: jhoblitt [...] cpan.org
Requestors: cpan [...] desert-island.me.uk
Cc:
AdminCc:

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



Subject: String with TZ -0700 fails to parse, unless..
Download (untitled) / with headers
text/plain 862b
From Facebook's Graph API: "2011-04-30T10:00:00-0700" fails to parse in v0.08: perl -MDateTime::Format::ISO8601 -le'print DateTime::Format::ISO8601->new()->parse_datetime("2011-04-30T10:00:00-0700")' Invalid date format: 2011-04-30T10:00:00-0700 at -e line 1. If I change "length" in this section: { #YYYYMMDDThhmmss[+-]hhmm 19850412T101530+0400 #YYYY-MM-DDThh:mm:ss[+-]hh:mm 1985-04-12T10:15:30+04:00 length => [ qw( 20 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 ) ], postprocess => \&_normalize_offset, }, to: length => [ qw( 20 24 25 ) ], then it parses fine..
Download (untitled) / with headers
text/plain 315b
On Thu Oct 29 10:38:23 2015, JROBINSON wrote: Show quoted text
> From Facebook's Graph API: "2011-04-30T10:00:00-0700" fails to parse > in v0.08:
Good catch. It looks like the \d{4} tz offset format somehow managed to escape being a test example. https://github.com/jhoblitt/DateTime-Format-ISO8601/blob/master/t/02_examples.t
Download (untitled) / with headers
text/plain 879b
On Thu, 29 Oct 2015 12:03:17 -0400, JHOBLITT wrote: Show quoted text
> On Thu Oct 29 10:38:23 2015, JROBINSON wrote:
> > From Facebook's Graph API: "2011-04-30T10:00:00-0700" fails to parse > > in v0.08:
> > Good catch. It looks like the \d{4} tz offset format somehow managed > to escape being a test example. > > https://github.com/jhoblitt/DateTime-Format- > ISO8601/blob/master/t/02_examples.t
Is this ticket still valid? Back in 2012 you had rejected a similar report (see RT #52645). Personally I'd also really like for this format to be supported for the following reasons: * the ISO spec you quoted (which I don't have access to) is unclear on this particular topic, really * formatting the time part with colons and the offset without is a fairly common mutation, to the point where GNU date on my machine prints this: $ date --iso-8601=seconds 2016-04-15T18:03:13+0200
Download (untitled) / with headers
text/plain 143b
I've packaged up the discussed change as a pull request if that's useful to anyone. https://github.com/jhoblitt/DateTime-Format-ISO8601/pull/1
Download (untitled) / with headers
text/plain 708b
Vid Fre, 15 apr 2016 kl. 12.05.55, skrev FGA: Show quoted text
> * the ISO spec you quoted (which I don't have access to) is unclear on > this particular topic, really
ISO 8601:2004 is very clear that the formatting should be either consistently in basic format or consistently in extended format. Section `4.3.2 Complete representations`, list every valid format and section `4.3.3 Representations other than complete` says the expression shall either be completely in basic format, in which case the minimum number of separators necessary for the required expression is used, or completely in extended format, in which case additional separators shall be used in accordance with 4.1 and 4.2 -- chansen
Download (untitled) / with headers
text/plain 583b
On 2016-04-15 12:05:55, FGA wrote: [...] Show quoted text
> * formatting the time part with colons and the offset without is a > fairly common mutation, to the point where GNU date on my machine > prints this: > > $ date --iso-8601=seconds > 2016-04-15T18:03:13+0200
This seems to be fixed in later versions of GNU coreutils: $ ssh cpansand@debian8.... 'date --iso-8601=seconds; date --version | head -1' 2018-08-03T15:29:03+0000 date (GNU coreutils) 8.23 $ ssh cpansand@debian9.... 'date --iso-8601=seconds; date --version | head -1' 2018-08-03T15:29:09+00:00 date (GNU coreutils) 8.26
Download (untitled) / with headers
text/plain 944b
On 2016-07-26 03:01:01, CHANSEN wrote: Show quoted text
> Vid Fre, 15 apr 2016 kl. 12.05.55, skrev FGA:
> > * the ISO spec you quoted (which I don't have access to) is unclear on > > this particular topic, really
> > ISO 8601:2004 is very clear that the formatting should be either > consistently in basic format or consistently in extended format. > > Section `4.3.2 Complete representations`, list every valid format > and section `4.3.3 Representations other than complete` says > > the expression shall either be completely in basic format, in > which case the minimum number of separators necessary for the > required expression is used, or completely in extended format, > in which case additional separators shall be used in accordance > with 4.1 and 4.2
A possibility would be to provide a sloppy=>1 parameter either in the constructor or in the parse_* methods or in both. At least it would be good to document these corner cases.


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

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.