Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#9028 closed defect (wontfix) Non-ISO Compliant

Reported by: Jarrod Carlson Owned by: Adam Peller
Priority: high Milestone: tbd
Component: Date Version: 0.9
Keywords: dojo date iso parser Cc:
Blocked By: Blocking:


According to the ISO 8601 standard on date-time formats:

The time zone offset can be listed as either "-04:00" or "-0400", both of which are equivalent. Currently, will return different dates for strings with a separator in the timezone:

Wed Apr 01 2009 10:30:00 GMT-0400 (EDT)
Wed Apr 01 2009 10:23:20 GMT-0400 (EDT)

Wed Apr 01 2009 13:30:00 GMT-0400 (EDT)
Wed Apr 01 2009 10:18:20 GMT-0400 (EDT)

The returned date has a margin of error dependent on the offset.

In fact, none of the separators in the string are required, save for the 'T' delineating the date and time, a localized indicator of the fraction of a second (ms), and the '+/-' indicating a positive or negative offset.

This issue can be resolved with the attached patch for

After the patch, the following works correctly:

Wed Apr 01 2009 13:30:00 GMT-0400 (EDT)
Wed Apr 01 2009 13:30:00 GMT-0400 (EDT)
Wed Apr 01 2009 13:30:00 GMT-0400 (EDT)

Attachments (1) (604 bytes) - added by Jarrod Carlson 13 years ago.

Download all attachments as: .zip

Change History (5)

Changed 13 years ago by Jarrod Carlson

Attachment: added

comment:1 Changed 13 years ago by Jarrod Carlson

ISO dates can also be specified as Week Dates or Ordinal Dates, but I'll leave that to another ticket (enhancement)

comment:2 Changed 13 years ago by Adam Peller

Milestone: 1.3.1tbd
Resolution: wontfix
Status: newclosed

ISO 8601 supports a lot of things which we don't. We've chosen a simple subset or profile of the standard, as specified in our docs, to implement for our timestamps to keep the code simple, fast, and small.

A more complete 8601 implementation might make sense in

comment:3 Changed 13 years ago by msmith

Can you please reconsider this fix? The patch is very simple, and already attached. It just updates the regex in, which won't have a performance impact on the processing at all.

This problem has been bothering me since the 0.9 conversion. I can get around it by modifying in my own code, but that's not quite eloquent.

Is there a reason for not allowing the separators to be optional?

comment:4 Changed 13 years ago by Adam Peller

@msmith: as with other things in the 0.9 conversion, we kept this deliberately limited choice. Exposing the isoRegexp for customization was a compromise. If other committers think it's a good idea to loosen up here, I won't object, but my instinct tells me to keep this method simple. We'd need to verify that it doesn't impact performance. Please note that the above regexp is not precise and would also allow

Note: See TracTickets for help on using tickets.