Bug 71371 – JSC on linux showing 3 additional regressions

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Andy Wingo]

Created attachment 113321 [details]
test results

On an x86-64 GNU/Linux system, I get the following results when I run JSC tests:


$ Tools/Scripts/run-javascriptcore-tests --gtk
Running: build-jsc --release --gtk
Running: jsDriver.pl -e squirrelfish -s /home/wingo/src/WebKit/WebKitBuild/Release/Programs/jsc -f actual.html -L ecma/Date/15.9.2.1.js ecma/Date/15.9.2.2-1.js ecma/Date/15.9.2.2-2.js ecma/Date/15.9.2.2-3.js ecma/Date/15.9.2.2-4.js ecma/Date/15.9.2.2-5.js ecma/Date/15.9.2.2-6.js ecma_3/Date/15.9.5.7.js
-#- Executing 1119 test(s).
...

-#- Wrote results to 'actual.html'.

** Danger, Will Robinson! Danger! The following failures have been introduced:
	ecma/Date/15.9.5.14.js
	ecma/Date/15.9.5.31-1.js
	ecma/Date/15.9.5.34-1.js

3 regressions found.
0 tests fixed.


I am not certain if this result is particular to the GTK port or not.  I have not yet looked into the root causes, here, but there are a couple of other bugs in other ports (bug 25160, bug 25161) that seem to indicate that this might not be an isolated issue.

Attaching the `actual.html' output.

[Andy Wingo]

Regarding the first case, the test prints:

  Testcase ecma/Date/15.9.5.14.js failed 
  Failure messages were:
  (new Date(1320254625004)).getHours() = 18 FAILED! expected: 19
  (new Date(1320258225004)).getHours() = 19 FAILED! expected: 20
  (new Date(1320261825004)).getHours() = 20 FAILED! expected: 21
  (new Date(1320265425004)).getHours() = 21 FAILED! expected: 22
  (new Date(1320269025004)).getHours() = 22 FAILED! expected: 23
  (new Date(1320272625004)).getHours() = 23 FAILED! expected: 0

FWIW these results are the same as I get with V8:


$ ./d8 
V8 version 3.6.5 (candidate) [console: dumb]
d8> (new Date(1320254625004)).getHours()
18
d8> (new Date(1320258225004)).getHours()
19
d8> (new Date(1320261825004)).getHours()
20
d8> (new Date(1320265425004)).getHours()
21
d8> (new Date(1320269025004)).getHours()
22
d8> (new Date(1320272625004)).getHours()
23


It appears to be a daylight-savings time issue.  This test appears to be disabled in Mozilla:

https://bugzilla.mozilla.org/show_bug.cgi?id=552218#c33

[Andy Wingo]

The second regression:

Testcase ecma/Date/15.9.5.31-1.js failed 
[ Previous Failure | Next Failure | Top of Page ]

Failure messages were:
TDATE = new Date(946684800000);(TDATE).setUTCHours(1234567);TDATE.getHours() = 8 FAILED! expected: 9

Produces the same in v8:

d8> TDATE = new Date(946684800000);(TDATE).setUTCHours(1234567);TDATE.getHours()  
8

In JSC, I get the same of course; the toString() is:

> TDATE.toString()
Wed Nov 02 2140 08:00:00 GMT+0100 (CET)

Note that it is in my time zone.  Were I in California, I think I would still have daylight-savings time.  Could this be the issue?

[Andy Wingo]

Finally for the third regression:

Testcase ecma/Date/15.9.5.34-1.js failed 
[ Previous Failure | Next Failure | Top of Page ]

Failure messages were:
TDATE = new Date(now); (TDATE).setMonth(11,31); TDATE.getTime() = 1325348626478 FAILED! expected: 1325352226478
TDATE = new Date(now); (TDATE).setMonth(11,31); TDATE.valueOf() = 1325348626478 FAILED! expected: 1325352226478
TDATE = new Date(now); (TDATE).setMonth(11,31); TDATE.getUTCHours() = 16 FAILED! expected: 17
TDATE = new Date(now); (TDATE).setMonth(11,31); TDATE.getHours() = 17 FAILED! expected: 18

For the first two cases, the values differ by 3600000, or 1 hour.  Likewise for the last two cases.  Given that I am currently in Europe in a non-daylight-savings-time locale, perhaps this is related.

[Andy Wingo]

Martin Robinson confirmed to me that these tests do not fail in the PST time zone.

[Andy Wingo]

In a totally awesome turn of events, now there is only one test failing: because now the US is on PST, not PDT.

** Danger, Will Robinson! Danger! The following failures have been introduced:
	ecma/Date/15.9.5.31-1.js

[Andy Wingo]

Created attachment 114076 [details]
Patch

[WebKit Review Bot]

Comment on attachment 114076 [details]
Patch

Clearing flags on attachment: 114076

Committed r99580: <http://trac.webkit.org/changeset/99580>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.