513115 - EMCA5: test failures in ecma_5/Date/15.9.4.2.js

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[David Mandelin [:dmandelin]]

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/15.9.4.2.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.

Comment 1

[Bruce Hoult]

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.

Comment 3

[Bruce Hoult]

If someone wants to back out the patch while I'm on holiday (and Graydon, who
reviewed it is too) then feel free.

Comment 4

[Jason Orendorff [:jorendorff]]

Heh - I've heard "it works on my machine" before, but never "works in my hemisphere". :)

Comment 5

[Jason Orendorff [:jorendorff]]

Attachment: v1

Comment 6

[David Mandelin [:dmandelin]]

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.

Comment 7

[Jason Orendorff [:jorendorff]]

http://hg.mozilla.org/tracemonkey/rev/6f6aeece5fe4

Comment 8

[Bob Clary [:bc] (inactive)]

v fixed in tracemonkey.

Comment 9

[Bruce Hoult]

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.

Comment 10

[Blake Kaplan (:mrbkap) (inactive)]

http://hg.mozilla.org/mozilla-central/rev/6f6aeece5fe4

Comment 11

[Robert Sayre]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/1e0da996def4

Comment 12

[Bob Clary [:bc] (inactive)]

v 1.9.3, 1.9.2