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.
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
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?
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.
Martin Robinson confirmed to me that these tests do not fail in the PST time zone.
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
Created attachment 114076 [details] Patch
Comment on attachment 114076 [details] Patch Clearing flags on attachment: 114076 Committed r99580: <http://trac.webkit.org/changeset/99580>
All reviewed patches have been landed. Closing bug.