RE: ISO 8601 Format YYYY-MM-DDThh:mm:ss.sss[+-]hhmm

>-----Original Message-----
>From: Zefram [mailto:[email protected]]
>Sent: 25 April 2012 11:04
>To: Carl Vincent
>Cc: [email protected]
>Subject: 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.

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