RE: ISO 8601 Format YYYY-MM-DDThh:mm:ss.sss[+-]hhmm
Thanks for that, I've posted a message to Salesforce though I don't expect any
useful response.
Whilst trawling for example code in DT::F::ISO8601, I did find that it would
happily parse week-number-based date times with mixed colon usage (although
only without dashes in the date).
$ DateTime::Format::ISO8601-parse_datetime('2012W144T10:39+');
2012-04-05T10:39:00
There seems to be quite a lot of inconsistency in exactly what's supported and
what's not.
Cheers
Carl
-Original Message-
From: Zefram [mailto:zef...@fysh.org]
Sent: 25 April 2012 11:32
To: Carl Vincent
Cc: datetime@perl.org
Subject: Re: ISO 8601 Format -MM-DDThh:mm:ss.sss[+-]hhmm
Carl Vincent wrote:
Do you have any reference from the official standard to this consistency
issue in the format? If so, I can take it up with Salesforce, since they
claim they're standards compliant and that's what's causing my pain.
Referring to ISO 8601:2004. Clauses 2.3.3 and 2.3.4, defining
basic format and extended format, apply the concept to an entire
date-and-time representation, rather than to segments of it, and doesn't
mention any possibility of mixing the formats. Clasue 4.2.5.2, defining
how to represent local time together with UT offset, separately shows
basic and extended formats where separator usage matches, and doesn't
give any explicit permission to mismatch them. Clause 4.3, on combining
date with time of day, behaves similarly.
-zefram
RE: ISO 8601 Format YYYY-MM-DDThh:mm:ss.sss[+-]hhmm
-Original Message- From: Zefram [mailto:zef...@fysh.org] Sent: 25 April 2012 11:04 To: Carl Vincent Cc: datetime@perl.org Subject: Re: ISO 8601 Format -MM-DDThh:mm:ss.sss[+-]hhmm Carl Vincent wrote: I can't see a case where the lack of a colon in the time offset introduces ambiguity in the parsing. It may be poor style, but it's not necessarily broken. You've got to be careful about this sort of thing when there's an actual standard. Once you start accepting something that's not really conforming, generators start relying on it being accepted, and then get surprised when stricter parsers reject it, and the usefulness of the standard to everyone is thus reduced. The permissiveness that you ask for is not free of cost. Look at what happened historically to the dotted-octet representation of IPv4 addresses, described in some detail at http://www.fysh.org/~zefram/text_rep/draft-main-ipaddr-text-rep.txt. Since these formats are out there in use, it would be better for the module to parse them Best for *a* module to parse them. A module that doesn't claim that they're actually ISO 8601 formats, and by extension probably not the module with ISO8601 in its name. DateTime::Format::SalesForce is available. I understand your concern, although a proliferation of slight variation modules will create confusion in it's own way. I'll attempt to construct a new module to parse the format. Do you have any reference from the official standard to this consistency issue in the format? If so, I can take it up with Salesforce, since they claim they're standards compliant and that's what's causing my pain. Regards Carl
Re: ISO 8601 Format YYYY-MM-DDThh:mm:ss.sss[+-]hhmm
Carl Vincent wrote:
$ DateTime::Format::ISO8601-parse_datetime('2012W144T10:39+');
2012-04-05T10:39:00
Oh, well spotted, that's entirely inconsistent. The input could correctly
be 2012-W14-4T10:39+00:00 or 2012W144T1039+.
-zefram
RE: ISO 8601 Format YYYY-MM-DDThh:mm:ss.sss[+-]hhmm
-Original Message- From: Zefram [mailto:zef...@fysh.org] Sent: 24 April 2012 18:14 To: datetime@perl.org Cc: Carl Vincent Subject: Re: ISO 8601 Format -MM-DDThh:mm:ss.sss[+-]hhmm Thomas Klausner wrote: Though I'm not sure why (beeing not familiar with the spec), my patch was rejected. ISO 8601 implies (but does not explicitly state) that you must be consistent within a single expression about whether you use the hyphen and colon separators (extended format). With the time of day expressed as 10:39:00.000, the UT offset should be expressed as +00:00, not +. So an ISO 8601 parser is justified in rejecting 10:39:00.000+. Since this is only an implicit requirement of the standard - and I don't have access to the full standard text, and I can't find reference to this elsewhere - is it necessary for its support to be excluded from the library? I can't see a case where the lack of a colon in the time offset introduces ambiguity in the parsing. It may be poor style, but it's not necessarily broken. Since these formats are out there in use, it would be better for the module to parse them if it's not going to introduce errors. I'm not suggesting we produce imperfectly styled ISO dates. What happened to the idea of being accommodating in what you accept and strict in what you produce? Carl -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Carl Vincent http://www.netskills.ac.uk/ (URL) Systems Manager 0191 222 5003 (voice) Netskills, Newcastle University 0191 222 5001 (fax) Netskills is a JISC Advance service Training - Development - Research - Innovation
Re: ISO 8601 Format YYYY-MM-DDThh:mm:ss.sss[+-]hhmm
Carl Vincent wrote: I can't see a case where the lack of a colon in the time offset introduces ambiguity in the parsing. It may be poor style, but it's not necessarily broken. You've got to be careful about this sort of thing when there's an actual standard. Once you start accepting something that's not really conforming, generators start relying on it being accepted, and then get surprised when stricter parsers reject it, and the usefulness of the standard to everyone is thus reduced. The permissiveness that you ask for is not free of cost. Look at what happened historically to the dotted-octet representation of IPv4 addresses, described in some detail at http://www.fysh.org/~zefram/text_rep/draft-main-ipaddr-text-rep.txt. Since these formats are out there in use, it would be better for the module to parse them Best for *a* module to parse them. A module that doesn't claim that they're actually ISO 8601 formats, and by extension probably not the module with ISO8601 in its name. DateTime::Format::SalesForce is available. -zefram
Re: ISO 8601 Format YYYY-MM-DDThh:mm:ss.sss[+-]hhmm
Hi!
On Tue, Apr 24, 2012 at 03:50:27PM +, Carl Vincent wrote:
I'm looking to parse a datetime from ISO8601 use DateTime::Format::ISO8601
2012-04-24T10:39:00.000+
I had a similar problem once:
https://rt.cpan.org/Public/Bug/Display.html?id=52645
(I submitted a patch to RT, even though it seems DT:F:ISO is one of the
modules that do not want to use RT)
Though I'm not sure why (beeing not familiar with the spec), my patch
was rejected.
For the record, this is the format I'm getting back from the SalesForce API...
I cannot remember what generated the wrong ISO8601, but I think it was
Perl or even DateTime itself... Will check..
Greetings,
domm
--
#!/usr/bin/perl http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
Re: ISO 8601 Format YYYY-MM-DDThh:mm:ss.sss[+-]hhmm
Thomas Klausner wrote: Though I'm not sure why (beeing not familiar with the spec), my patch was rejected. ISO 8601 implies (but does not explicitly state) that you must be consistent within a single expression about whether you use the hyphen and colon separators (extended format). With the time of day expressed as 10:39:00.000, the UT offset should be expressed as +00:00, not +. So an ISO 8601 parser is justified in rejecting 10:39:00.000+. -zefram
