Closed Bug 693077 Opened 8 years ago Closed 8 years ago

Date.parse should accept strings with local time offset like 2011-10-04T17:52:00+0200


(Core :: XPConnect, enhancement)

8 Branch
Not set



Tracking Status
firefox8 + ---
firefox9 + ---


(Reporter: aryx, Unassigned)



(Keywords: regression)

After ISO 8601 string parsing has been moved from ISO8601DateUtils.jsm to Date.parse (bug 543535 and bug 430930), there is no native facility to parse datetime strings with a local time offset attached, for example "2011-10-04T17:52:00+0200"

Firefox 7 parses successfully with

returns NaN.
Since bug 543535 should have covered all use cases for ISO8601DateUtils.jsm, I'm requesting this to be tracked for Firefox 8.
Assignee: general → nobody
Component: JavaScript Engine → XPConnect
OS: Windows XP → All
QA Contact: general → xpconnect
Hardware: x86 → All
Version: Trunk → 8 Branch
Phil, Andreas, do we need to back out bug 543535?
Blocks: 543535
Only if we feel that parsing a datetime which is not an ISO8601 datetime with something that claims it is parsing ISO8601 is an absolute requirement.

Otherwise, I think a better way forward would be for someone to quietly take me aside and explain to me how to fix up the test to address my review comments in bug 682754 so that Fx 10 or 11 or whatever will parse those non-ISO8601 datetimes, and in the meantime we should encourage people to stick the colon that is required to be in the timezone offset in the timezone offset.
Ah, so if the string were "2011-10-04T17:52:00+02:00" it would work?

Catch me on irc (Tuesday) and we'll talk about bug 682754, ok?
Yeah, umpteen times a day does Date.parse with +12:00 and -07:00, which ought to mean it has the direction of the signs right, so it better get +02:00 right, too.

But, ISO8601DateUtils did not actually parse "2011-10-04T17:52:00+0200". What it parsed was "2011-10-04T17:52:00Mojibakefjklzdse". I was just coming around to the point where I would have said "but I don't really care whether we back it out for Fx 8" when I looked to see how I missed the feature of ISO8601DateUtils that fixed missing-colon timezones , and discovered that I did not miss it. (Z|([+-])(\d{2}):?(\d{2}))?)?$/ would have been a feature, but (Z|([+-])(\d{2}):(\d{2}))?)?/ was an ugly misfeature, silently saying that it was a date in the local machine's timezone.
Okay, bug 682754 is inbound. If I came across this bug without all sorts of flags set, I'd just mark it as a duplicate of that.

If you want to do that, cool. If you want to take bug 682754 for aurora or beta... I wouldn't, but I'm an over-cautious driver. It is dead simple, and as far as I can see unambiguous, though apparently Chrome is the only other browser that does it too.

If you want to reland the broken, bad idea filled ISO8601DateUtils, it's no skin off my nose, but you should be able to get the same effect by recommending to the 9 addons that bug 543535 comment 8 said were using it that they just copy-paste the <30 lines of code into their own code (and test it, like we never did, and fix it).
OK, so the patch for bug 682754 should fix this one. I'd like to request that patch to be applied for Aurora and Beta as well. Reverting to ISO8601DateUtils sounds like a bad idea since it was clearly buggy in its parsing.
In reply to Phil Ringnalda (:philor) from comment #3:
> parse those non-ISO8601 datetimes, and in the meantime we should encourage people to
> stick the colon that is required to be in the timezone offset in the timezone offset.

From what I read, the colon in the timezone is optional per ISO 8601:
'The offset from UTC is given in the format ±[hh]:[mm], ±[hh][mm], or ±[hh]. So, ... the zone designator would be "+01:00", "+0100", or simply "+01".' <>
'The strings +hh:mm, +hhmm, or +hh can be added to the time to indicate that the used local time zone is hh hours and mm minutes ahead of UTC.' <>
Yeah, but the actual standard is a bit stricter than that, as far as I can tell.  If I read it right, then "20111004T175200+0200" is a valid ISO 8601 date (which Date.parse does not handle, note) and "2011-10-04T17:52:00+02:00" is a valid ISO 8601 date, but things that leave off _some_ of the separators are not...

It's hard to tell, though; this particular standard is not very clearly written.  And of course if people ignore it in practice it may not matter much.

You can read the actual standard at
Closed: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 682754
You need to log in before you can comment on or make changes to this bug.