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
> [email protected]
> https://mail.mozilla.org/listinfo/test262-discuss
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
