Judging by the discussion in bug 430930, at the time ES5 had not yet gotten around to including the language now in 188.8.131.52, "The value of an absent time zone offset is "Z"." Because that wasn't specified, but 184.108.40.206 said (as it still does, now incompatibly with 220.127.116.11) "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.", bug 430930 decided that the only way a String could be interpreted as a local time would be to treat an absent time zone offset as local.
Unfortunately, 18.104.22.168 is explicit about saying it is not, and 22.214.171.124 says "first attempts to parse the format of the String according to the rules called out in Date Time String Format (126.96.36.199)" so what we are doing now, treating 20111030T22:13:00 as a local time, is wrong.
Created attachment 570613 [details] [diff] [review]
Ah, interesting, I see that the edition 6 draft is explicit about saying that it is a local time rather than UTC.
Try run for 566fe84e57ca is complete.
Detailed breakdown of the results available here:
Results (out of 33 total builds):
Builds available at http://email@example.com
good that the spec now says local time. That makes sense, and that's what we do.