Date.parse() sematics / internationalization

Allen Wirfs-Brock allen at wirfs-brock.com
Fri Mar 15 11:23:16 PDT 2013


On Mar 14, 2013, at 3:20 AM, Paul Ruizendaal wrote:

> There seems to be ambiguity over the semantics of Date.parse() in the spec (both 5.1 and latest 6 draft).
> 
> The spec says: " The String may be interpreted as a local time, a UTC time, or a time in some other time zone, depending on the contents of the String." Note that it doesn't say "depending on the implementation".

But the next two sentences say:  "The function first attempts to parse the format of the String according to the rules called out in Date Time String Format (15.9.1.15). If the String does not conform to that format the function may fall back to any implementation-specific heuristics or implementation-specific date formats." (italics added)

> 
> In a quick test of Date.parse("1970T23:35:22") I got the following results:
> - Chrome: UTC time
> - Firefox: local time
> - IE9: UTC time
> - Safari: fails on this pattern, but "Thu Jan 1 1970 23:35:22" gets interpreted as local time
> 
> Section 15.9.1.15 does not seem to specify when to interpret the string as local and when UTC. In my reading it is implied that a string is interpreted as local unless a time zone specifier is added (possibly UTC+00:00). However this seems to be at odds with the interpretation at MS/Google, and I must admit that interpretation as UTC seemed logical to me before I got deeply into this.

see
https://bugs.ecmascript.org/show_bug.cgi?id=112 
https://bugs.ecmascript.org/show_bug.cgi?id=342 


> 
> There is no test for this in test262. Moreover, test262 is currently badly broken on timezone handling with the timezone hardcoded to California Summer time (see bug 293 and 330). The earlier Sputnik code got it mostly right for folks all around the globe but was of by a week with DST start/stop time in California. I would recommend that the hardcoding is backed out again and that timezone handling reverts to the Sputnik timezone logic (Dave Fugate left MS shortly after doing the hardcoding -- I guess he never got around to doing a proper fix). With that in place, writing tests for Date.parse() semantics is trivial and I'm happy to contribute.

You should file test262 bugs, if you haven't already.
> 
> Paul
> 
> _______________________________________________
> test262-discuss mailing list
> test262-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/test262-discuss
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130315/7abdc817/attachment.html>


More information about the es-discuss mailing list