Last Comment Bug 693077 - Date.parse should accept strings with local time offset like 2011-10-04T17:52:00+0200
: Date.parse should accept strings with local time offset like 2011-10-04T17:52...
Status: RESOLVED DUPLICATE of bug 682754
: regression
Product: Core
Classification: Components
Component: XPConnect (show other bugs)
: 8 Branch
: All All
: -- enhancement (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Andrew Overholt [:overholt]
Mentors:
Depends on:
Blocks: 543535
  Show dependency treegraph
 
Reported: 2011-10-08 10:32 PDT by Sebastian Hengst [:aryx][:archaeopteryx] (needinfo on intermittent or backout)
Modified: 2013-12-27 14:20 PST (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+
+


Attachments

Description Sebastian Hengst [:aryx][:archaeopteryx] (needinfo on intermittent or backout) 2011-10-08 10:32:27 PDT
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
Components.utils.import("resource://gre/modules/ISO8601DateUtils.jsm");
alert(ISO8601DateUtils.parse("2011-10-04T17:52:00+0200"));

while
alert(Date.parse("2011-10-04T17:52:00+0200"));
returns NaN.
Comment 1 Jorge Villalobos [:jorgev] 2011-10-10 09:59:12 PDT
Since bug 543535 should have covered all use cases for ISO8601DateUtils.jsm, I'm requesting this to be tracked for Firefox 8.
Comment 2 Boris Zbarsky [:bz] (still a bit busy) 2011-10-10 18:47:25 PDT
Phil, Andreas, do we need to back out bug 543535?
Comment 3 Phil Ringnalda (:philor) 2011-10-10 19:01:14 PDT
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.
Comment 4 Boris Zbarsky [:bz] (still a bit busy) 2011-10-10 21:53:02 PDT
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?
Comment 5 Phil Ringnalda (:philor) 2011-10-10 23:37:27 PDT
Yeah, umpteen times a day http://mxr.mozilla.org/mozilla-beta/source/js/src/tests/ecma_5/Date/15.9.4.2.js 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.
Comment 6 Phil Ringnalda (:philor) 2011-10-11 21:13:29 PDT
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).
Comment 7 Jorge Villalobos [:jorgev] 2011-10-12 10:10:43 PDT
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.
Comment 8 Ben Bucksch (:BenB) 2011-10-18 07:42:13 PDT
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".' <http://en.wikipedia.org/wiki/ISO_8601>
'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.' <http://www.cl.cam.ac.uk/~mgk25/iso-time.html>
Comment 9 Boris Zbarsky [:bz] (still a bit busy) 2011-10-18 09:00:13 PDT
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 http://dotat.at/tmp/ISO_8601-2004_E.pdf
Comment 10 Phil Ringnalda (:philor) 2011-10-24 00:15:16 PDT

*** This bug has been marked as a duplicate of bug 682754 ***

Note You need to log in before you can comment on or make changes to this bug.