Bug #23307 for DateTime-Format-ISO8601: YYYY-MM-DD HH:MM:SS not a valid datetime

Wed Nov 15 04:44:13 2006 mschwern [...] cpan.org - Ticket created

Subject:

YYYY-MM-DD HH:MM:SS not a valid datetime

$ perl -MDateTime::Format::ISO8601 -wle '$dt = DateTime::Format::ISO8601->new; $dt->parse_datetime( "2006-11-15 04:32:51" )' Invalid date format: 2006-11-15 04:32:51 at -e line 1 $ perl -MDateTime::Format::ISO8601 -wle 'DateTime::Format::ISO8601->parse_datetime( "2006-11-15 04:32:51" )' Invalid date format: 2006-11-15 04:32:51 at -e line 1 That should be a valid ISO date. The T separator should be optional and is documented as such in the man page. This is ISO8601 0.0403 + DateTime 0.35.

Wed Nov 15 05:41:38 2006 jhoblitt [...] cpan.org - Correspondence added

From:

JHOBLITT [...] cpan.org

On Wed Nov 15 04:44:13 2006, MSCHWERN wrote: Show quoted text

> $ perl -MDateTime::Format::ISO8601 -wle '$dt = > DateTime::Format::ISO8601->new; $dt->parse_datetime( "2006-11-15 > 04:32:51" )' > Invalid date format: 2006-11-15 04:32:51 at -e line 1 > > $ perl -MDateTime::Format::ISO8601 -wle > 'DateTime::Format::ISO8601->parse_datetime( "2006-11-15 04:32:51" )' > Invalid date format: 2006-11-15 04:32:51 at -e line 1

It's my belief that is not a valid ISO8601 format. Although, it is in common use by MySQL, apache, etc. AFAIK none of those projects claim that it's an ISO8601 format either. Several other DT::F parser understand that format including DT::F::MySQL & DT::F::HTTP so I'm not sure it's worth while for DT::F::ISO8601 to accept a non-standard format even if they are in common use. Show quoted text

> That should be a valid ISO date. The T separator should be optional and > is documented as such in the man page. > > This is ISO8601 0.0403 + DateTime 0.35.

The manual doesn't state that for section 5.4 format times. The standard says in a foot note: "NOTE By mutual agreement of the partners in information interchange, the character [T] may be omitted in applicationswhere there is no risk of confusing a combined date and time of the day representation with others defined in this International Standard." When "ommited" is used else where in the standard it doesn't mean "can be replaced with a space". In deed, non of the provided examples use a space in that manner. So "2006-11-1504:32:51" is a valid format but only if a special agreement has been made between the exchanging parties. I'd be willing to change the parser to allow the T to be "ommited" in all of the section 5.4 formats if you like.

Wed Nov 15 05:41:39 2006 The RT System itself - Status changed from 'new' to 'open'

Wed Nov 15 18:39:55 2006 schwern [...] pobox.com - Correspondence added

CC:	MSCHWERN [...] cpan.org
Subject:	Re: [rt.cpan.org #23307] YYYY-MM-DD HH:MM:SS not a valid datetime
Date:	Wed, 15 Nov 2006 15:39:24 -0800
To:	bug-DateTime-Format-ISO8601 [...] rt.cpan.org
From:	Michael G Schwern <schwern [...] gmail.com>

via RT wrote: Show quoted text

>> $ perl -MDateTime::Format::ISO8601 -wle >> 'DateTime::Format::ISO8601->parse_datetime( "2006-11-15 04:32:51" )' >> Invalid date format: 2006-11-15 04:32:51 at -e line 1

> > It's my belief that is not a valid ISO8601 format. Although, it is in > common use by MySQL, apache, etc. AFAIK none of those projects claim > that it's an ISO8601 format either.

You're right, my bad. Show quoted text

> Several other DT::F parser > understand that format including DT::F::MySQL & DT::F::HTTP so I'm not > sure it's worth while for DT::F::ISO8601 to accept a non-standard format > even if they are in common use.

Well, it would be nice not to have to use an application specific date format parser for what is a very common mutation of the ISO8601 format. And then there's the DWIMness. Maybe have a "strict" flag which can be turned on and off? Perhaps the place to do this is in the DateTime default format parser. Show quoted text

>> That should be a valid ISO date. The T separator should be optional and >> is documented as such in the man page. >> >> This is ISO8601 0.0403 + DateTime 0.35.

> > The manual doesn't state that for section 5.4 format times. The > standard says in a foot note: "NOTE By mutual agreement of the > partners in information interchange, the character [T] may be omitted in > applicationswhere there is no risk of confusing a combined date and time > of the day representation with others defined in this International > Standard." When "ommited" is used else where in the standard it doesn't > mean "can be replaced with a space". In deed, non of the provided > examples use a space in that manner. So "2006-11-1504:32:51" is a valid > format but only if a special agreement has been made between the > exchanging parties. I'd be willing to change the parser to allow the T > to be "ommited" in all of the section 5.4 formats if you like.

Uhhh... I don't think that helps me.

Wed Nov 15 18:55:57 2006 jhoblitt [...] cpan.org - Correspondence added

From:

JHOBLITT [...] cpan.org

On Wed Nov 15 18:39:55 2006, schwern@pobox.com wrote: Show quoted text

> Well, it would be nice not to have to use an application specific date > format parser for what is a very common mutation of the ISO8601 > format. And then there's the DWIMness. Maybe have a "strict" flag > which can be turned on and off? > > Perhaps the place to do this is in the DateTime default format parser.

I'm not sure if this parser should be pedantic or permissive by default since there are so many other "general" parsers already. I'll float this issue on the datatime list and see what others think.

Sun Sep 16 06:04:19 2007 mschwern [...] cpan.org - Correspondence added

On Wed Nov 15 18:55:57 2006, JHOBLITT wrote: Show quoted text

> On Wed Nov 15 18:39:55 2006, schwern@pobox.com wrote:

> > Well, it would be nice not to have to use an application specific date > > format parser for what is a very common mutation of the ISO8601 > > format. And then there's the DWIMness. Maybe have a "strict" flag > > which can be turned on and off? > > > > Perhaps the place to do this is in the DateTime default format parser.

> > I'm not sure if this parser should be pedantic or permissive by default > since there are so many other "general" parsers already. I'll float > this issue on the datatime list and see what others think.

So I have another need for this. I need to be able to handle RFC 3339 (simplified ISO 8601) which does allow a space. NOTE: ISO 8601 defines date and time separated by "T". Applications using this syntax may choose, for the sake of readability, to specify a full-date and full-time separated by (say) a space character. TAP Datetime does just that. http://testanything.org/wiki/index.php/TAP_datetime Here's the options I see. 1) Make the ISO8601 parser permissive, or have a flag. 2) Change the stock DateTime parser to handle RFC 3339 3) Write an RFC3339 parser based on your ISO8601. They're not mutually exclusive, #3 can always be done.

Mon Sep 17 17:06:50 2007 jhoblitt [...] ifa.hawaii.edu - Correspondence added

CC:	datetime [...] perl.org
Subject:	Re: [rt.cpan.org #23307] YYYY-MM-DD HH:MM:SS not a valid datetime
Date:	Mon, 17 Sep 2007 11:13:55 -1000
To:	Michael G Schwern via RT <bug-DateTime-Format-ISO8601 [...] rt.cpan.org>
From:	Joshua Hoblitt <jhoblitt [...] ifa.hawaii.edu>

I haven't given RFC 3339 an in depth study but it appears to be a significant simplification of ISO 8601:2000. As you note, it's not really just a subset either as not all valid RFC 3339 formats are valid ISO 8601 formats because of the time & date separator relaxation. It's also not clear to me if independent date or time formats are allowed. The ABNF is incorrect in that it doesn't allow for the "space" separator in place of "T". I would be tempted to make a parser for this RFC live in a new namespace, e.g. DateTime::Format::RFC3339, regardless of how much code (and tests) are shared. It probably makes sense to bundle it with DT:F::ISO8601 as well. How urgently do you need this? Cheers, -J -- On Sun, Sep 16, 2007 at 06:04:20AM -0400, Michael G Schwern via RT wrote: Show quoted text

> > Queue: DateTime-Format-ISO8601 > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=23307 > > > On Wed Nov 15 18:55:57 2006, JHOBLITT wrote:

> > On Wed Nov 15 18:39:55 2006, schwern@pobox.com wrote:

> > > Well, it would be nice not to have to use an application specific date > > > format parser for what is a very common mutation of the ISO8601 > > > format. And then there's the DWIMness. Maybe have a "strict" flag > > > which can be turned on and off? > > > > > > Perhaps the place to do this is in the DateTime default format parser.

> > > > I'm not sure if this parser should be pedantic or permissive by default > > since there are so many other "general" parsers already. I'll float > > this issue on the datatime list and see what others think.

> > So I have another need for this. I need to be able to handle RFC 3339 > (simplified ISO 8601) which does allow a space. > > NOTE: ISO 8601 defines date and time separated by "T". > Applications using this syntax may choose, for the sake of > readability, to specify a full-date and full-time separated by > (say) a space character. > > TAP Datetime does just that. > http://testanything.org/wiki/index.php/TAP_datetime > > Here's the options I see. > > 1) Make the ISO8601 parser permissive, or have a flag. > 2) Change the stock DateTime parser to handle RFC 3339 > 3) Write an RFC3339 parser based on your ISO8601. > > They're not mutually exclusive, #3 can always be done.

Download (untitled)
application/pgp-signature 189b

Message body not shown because it is not plain text.

Mon Sep 17 17:36:22 2007 schwern [...] pobox.com - Correspondence added

Subject:	Re: [rt.cpan.org #23307] YYYY-MM-DD HH:MM:SS not a valid datetime
Date:	Mon, 17 Sep 2007 14:35:43 -0700
To:	bug-DateTime-Format-ISO8601 [...] rt.cpan.org
From:	Michael G Schwern <schwern [...] pobox.com>

Joshua Hoblitt via RT wrote: Show quoted text

> <URL: http://rt.cpan.org/Ticket/Display.html?id=23307 > > > I haven't given RFC 3339 an in depth study but it appears to be a > significant simplification of ISO 8601:2000. As you note, it's not > really just a subset either as not all valid RFC 3339 formats are valid > ISO 8601 formats because of the time & date separator relaxation. It's > also not clear to me if independent date or time formats are allowed. > The ABNF is incorrect in that it doesn't allow for the "space" separator > in place of "T".

I noted that, too. All of it's examples are full date times with the T separator. The TAP datetime format gets around this by explicitly stating those assumptions in it's grammar. tap_datetime = rfc_3339_date " " rfc_3339_time | rfc_3339_date | rfc_3339_time | rfc_3339_datetime rfc_3339_date = As RFC 3339 section 5.6 "full-date" rfc_3339_time = As RFC 3339 section 5.6 "full-time" rfc_3339_datetime = As RFC 3339 section 5.6 "date-time" Show quoted text

> I would be tempted to make a parser for this RFC live in a new > namespace, e.g. DateTime::Format::RFC3339, regardless of how much code > (and tests) are shared. It probably makes sense to bundle it with > DT:F::ISO8601 as well.

Yeah, that makes sense. Show quoted text

> How urgently do you need this?

Not urgently enough that I haven't gone and written it myself. :) Just thought I'd note it for the record as this issue keeps popping up. -- Whip me, beat me, make my code compatible with VMS!

Mon Sep 17 18:21:08 2007 rickm [...] isite.net.au - Correspondence added

CC:	Michael G Schwern via RT <bug-DateTime-Format-ISO8601 [...] rt.cpan.org>, datetime [...] perl.org
Subject:	Re: [rt.cpan.org #23307] YYYY-MM-DD HH:MM:SS not a valid datetime
Date:	Tue, 18 Sep 2007 08:18:34 +1000
To:	Joshua Hoblitt <jhoblitt [...] ifa.hawaii.edu>
From:	Rick Measham <rickm [...] isite.net.au>

Joshua Hoblitt wrote: Show quoted text

> I would be tempted to make a parser for this RFC live in a new > namespace, e.g. DateTime::Format::RFC3339, regardless of how much code > (and tests) are shared. It probably makes sense to bundle it with > DT:F::ISO8601 as well.

Interestingly, I was going to point the list to the W3C spec that is basically the same format, just less formally defined: http://www.w3.org/TR/NOTE-datetime I most certainly think it should be its own Format module so that the parser can die on a valid ISO8601 date that is invalid in RFC3339 Writing the module would not be a problem for any experienced DateTimer. I don't think it makes sense to bundle it with ISO8601 as it's only relationship is that it happens to be a subset of the ISO8601 rules. It is it's own format, and I'd prefer to have it in its own distribution in order to make it clear that it is a valid, independent, format. Cheers! Rick Measham

Thu Jan 20 14:57:15 2011 DOUGW [...] cpan.org - Correspondence added

On Mon Sep 17 18:21:08 2007, rickm@isite.net.au wrote: Show quoted text

> Joshua Hoblitt wrote: > > I most certainly think it should be its own Format module so that the > parser can die on a valid ISO8601 date that is invalid in RFC3339 >

Just thought I'd mention that someone has written a DateTime::Format::RFC3339 and it still doesn't support a space between the date and the time, so if someone still feels it's an issue, they should open a ticket over there.

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