Closed Bug 513115 Opened 12 years ago Closed 12 years ago
EMCA5: test failures in ecma
_5/Date/15 .9 .4 .2 .js
Command, run in PT on Aug 27 2009 (some call it PDT): $(JS) -f shell.js -f ecma_5/shell.js -f ecma_5/Date/shell.js -f ecma_5/Date/184.108.40.206.js failure outputs: FAILED! [reported from test()] Date.parse('T19:53:21.001') == '1970-01-02T02:53:21.001Z' : Expected value '96801001', Actual value '100401001' FAILED! [reported from test()] Date.parse('T19:53:21') == '1970-01-02T02:53:21.000Z' : Expected value '96801000', Actual value '100401000' FAILED! [reported from test()] Date.parse('T19:53') == '1970-01-02T02:53:00.000Z' : Expected value '96780000', Actual value '100380000' Probably related to time zones per discussion w/ Bruce.
It is difficult to say as the specification is very under defined, but in my opinion the test is correct and the code is buggy. It works in any time zone except those where it is both the northern hemisphere and currently daylight saving time. That is, it works in the southern hemisphere at any time, and in the northern hemisphere in winter.
Status: NEW → ASSIGNED
If someone wants to back out the patch while I'm on holiday (and Graydon, who reviewed it is too) then feel free.
Heh - I've heard "it works on my machine" before, but never "works in my hemisphere". :)
Assignee: bruce → jorendorff
Attachment #398376 - Flags: review?(dmandelin)
Attachment #398376 - Flags: review?(dmandelin) → review+
Comment on attachment 398376 [details] [diff] [review] v1 That seemed like the right thing to do to me as well, when I first looked at this.
v fixed in tracemonkey.
I really wanted the code to have been wrong here, not the test, in order to try to make a pretty identity that: Date.parse(dateStr) + Date.parse(timeStr) == Date.parse(dateStr+timeStr) Unfortunately that can never work when the timezone is not specified. You'd have to adjust one, but not both, of the date and the time for the current time zone. You can't apply the correct local time zone to UTC correction to the time because you don't know the date so you don't know whether to allow for daylight savings time. And you can't apply a time zone adjustment to the date because you don't know whether the time it will be added to will have an explicit or an implied timezone. So that dream was unrealistic :-( So having pure times with an implied timezone be adjusted for the time zone offset at Jan 1 (rather than the current date) is probably the best that can be done. It does make one wonder what practical use they are though. It would be really nice if the specification specified all this behaviour, otherwise there's a good chance we're guessing differently to other implementations.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
v 1.9.3, 1.9.2
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.