Skip Menu |

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

Report information
The Basics
Id: 108082
Status: resolved
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)

History Show all quoted text
  Thu Oct 29 10:38:23 2015 cpan [...] desert-island.me.uk - Ticket created
Subject: String with TZ -0700 fails to parse, unless..
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..
  Thu Oct 29 10:38:42 2015 cpan [...] desert-island.me.uk - Severity Important added
  Thu Oct 29 12:01:15 2015 jhoblitt [...] cpan.org - Status changed from 'new' to 'open'
  Thu Oct 29 12:01:16 2015 jhoblitt [...] cpan.org - Taken
  Thu Oct 29 12:03:17 2015 jhoblitt [...] cpan.org - Correspondence added
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
  Fri Apr 15 12:05:55 2016 FGA [...] cpan.org - Correspondence added
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
  Wed Jul 20 11:03:06 2016 DRAXIL [...] cpan.org - Correspondence added
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
  Tue Jul 26 03:01:01 2016 chansen [...] cpan.org - Correspondence added
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
  Fri Aug 03 11:30:35 2018 SREZIC [...] cpan.org - Correspondence added
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
  Fri Aug 03 11:34:04 2018 SREZIC [...] cpan.org - Correspondence added
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.
  Sat Jul 25 12:57:14 2020 DROLSKY [...] cpan.org - Correspondence added
Ticket migrated to GitHub as https://github.com/houseabsolute/DateTime-Format-ISO8601/issues/7
  Sat Jul 25 12:57:15 2020 DROLSKY [...] cpan.org - Status changed from 'open' to 'resolved'