When my computers timezone is set to NZST run-javascriptcore-tests tells me that 33 regressions have been found. Changing to PDT results in 0 regressions. The following tests are the ones that experience regressions, with the output shown at http://bdash.net.nz/files/webkit/jscore-date- regressions.html. ecma/Date/15.9.3.1-1.js ecma/Date/15.9.3.2-1.js ecma/Date/15.9.3.8-1.js ecma/Date/15.9.3.8-2.js ecma/Date/15.9.5.10-12.js ecma/Date/15.9.5.14.js ecma/Date/15.9.5.22-1.js ecma/Date/15.9.5.22-3.js ecma/Date/15.9.5.23-1.js ecma/Date/15.9.5.23-15.js ecma/Date/15.9.5.23-17.js ecma/Date/15.9.5.24-1.js ecma/Date/15.9.5.24-5.js ecma/Date/15.9.5.25-1.js ecma/Date/15.9.5.26-1.js ecma/Date/15.9.5.27-1.js ecma/Date/15.9.5.29-1.js ecma/Date/15.9.5.30-1.js ecma/Date/15.9.5.31-1.js ecma/Date/15.9.5.32-1.js ecma/Date/15.9.5.33-1.js ecma/Date/15.9.5.34-1.js ecma/Date/15.9.5.35-1.js ecma/Date/15.9.5.36-1.js ecma/Date/15.9.5.36-2.js ecma/Date/15.9.5.36-3.js ecma/Date/15.9.5.36-4.js ecma/Date/15.9.5.36-5.js ecma/Date/15.9.5.36-6.js ecma/Date/15.9.5.36-7.js ecma/Date/15.9.5.37-1.js ecma/Date/15.9.5.8.js ecma_3/Date/15.9.5.6.js
(In reply to comment #0) > When my computers timezone is set to NZST run-javascriptcore-tests tells me that 33 regressions have > been found. Changing to PDT results in 0 regressions. The following tests are the ones that > experience regressions, with the output shown at http://bdash.net.nz/files/webkit/jscore-date- > regressions.html. > > ecma/Date/15.9.3.1-1.js > ecma/Date/15.9.3.2-1.js > ecma/Date/15.9.3.8-1.js > ecma/Date/15.9.3.8-2.js > ecma/Date/15.9.5.10-12.js > ecma/Date/15.9.5.14.js > ecma/Date/15.9.5.22-1.js > ecma/Date/15.9.5.22-3.js > ecma/Date/15.9.5.23-1.js > ecma/Date/15.9.5.23-15.js > ecma/Date/15.9.5.23-17.js > ecma/Date/15.9.5.24-1.js > ecma/Date/15.9.5.24-5.js > ecma/Date/15.9.5.25-1.js > ecma/Date/15.9.5.26-1.js > ecma/Date/15.9.5.27-1.js > ecma/Date/15.9.5.29-1.js > ecma/Date/15.9.5.30-1.js > ecma/Date/15.9.5.31-1.js > ecma/Date/15.9.5.32-1.js > ecma/Date/15.9.5.33-1.js > ecma/Date/15.9.5.34-1.js > ecma/Date/15.9.5.35-1.js > ecma/Date/15.9.5.36-1.js > ecma/Date/15.9.5.36-2.js > ecma/Date/15.9.5.36-3.js > ecma/Date/15.9.5.36-4.js > ecma/Date/15.9.5.36-5.js > ecma/Date/15.9.5.36-6.js > ecma/Date/15.9.5.36-7.js > ecma/Date/15.9.5.37-1.js > ecma/Date/15.9.5.8.js > ecma_3/Date/15.9.5.6.js Yes, this is the case on my development box too, I have noticed this **CONFIRMED**! This has been like this for a while, The time zone here is Australia/Melbourne/Victoria (GMT +10). I would like to investigate into this bugger, and quash it. Chris.
Could we see some tests or examples? fixed on r17444.
Created attachment 11290 [details] Output of run-javascriptcore-tests with r17446.
The failing date tests all now appear to be off by one.
fixed some tests, see r17520
So the underlying issue here is that localtime() returns historically accurate information (e.g. NZ did not have DST from 1946 to 1974), but the JavaScript standard explicitly states that historically information should be ignored (wrt DST) and instead should be interpolated from valid years. Where "valid" is years with the same leapness and Jan 1st is on the same day of the week. See 15.9.1.9 Daylight Saving Time Adjustment in http://bclary.com/2004/11/07/ecma-262
Only 4 regressions remains on r18075 ecma/Date/15.9.5.10-1.js ecma/Date/15.9.5.12-1.js ecma/Date/15.9.5.28-1.js ecma/Date/15.9.5.29-1.js
It has become more and more apparent to me how the javascript standard specifies dates to work and how are tests are really designed from the PST standpoint. What we need to do IMHO is create timezone specific tests (e.g. that test for DST on certain dates, which are not universal), instead of assuming that the PST tests will work everywhere.
*** Bug 16543 has been marked as a duplicate of this bug. ***
*** Bug 24858 has been marked as a duplicate of this bug. ***
Created attachment 28989 [details] patch to force time zone to PST8PDT when running tests Here's a patch I originally attached to bug 24858. It forces the time zone to PST8PDT when running regression tests. But maybe we want to change the tests instead of the test harness?
testapi fails when the time zone is not Pacific. The failing test is <http://trac.webkit.org/browser/trunk/JavaScriptCore/API/tests/testapi.c?rev=41931#L1061>: assertEqualsAsUTF8String(o, "Wed Dec 31 1969 16:00:00 GMT-0800 (PST)");
Comment on attachment 28989 [details] patch to force time zone to PST8PDT when running tests This patch actually seems to introduce more failures than it fixes, at least for someone in Eastern Time.
*** Bug 19553 has been marked as a duplicate of this bug. ***
Comment on attachment 28989 [details] patch to force time zone to PST8PDT when running tests This patch causes regressions, which is why it wasn't marked for review. Clearing the r+ flag.
Oh sorry I was a little too quick there.
*** Bug 7998 has been marked as a duplicate of this bug. ***
I just started running the run-javascriptcore-tests, live/work in the Eastern time zone, and am seeing one test failure: ----- actual.html snippet ----- Testcase ecma/Date/15.9.5.12-6.js failed Failure messages were: (new Date(973396800000)).getDay() = 0 FAILED! expected: 6 ----- actual.html snippet ----- From Web Inspector on the latest nightly: > new Date(973396800000) Sun Nov 05 2000 00:00:00 GMT-0400 (EDT) > (new Date(973396800000)).getDay() 0 From Chrome devtools (latest Mac beta): > new Date(973396800000) Sat Nov 04 2000 23:00:00 GMT-0500 (EST) > (new Date(973396800000)).getDay() 6
I got the 4 failures with JST timezone: ecma/Date/15.9.5.28-1.js ecma/Date/15.9.5.29-1.js ecma/Date/15.9.5.31-1.js ecma/Date/15.9.5.35-1.js Note that when I run with TZ=Americas/Los_Angeles, all tests pass.
Mozilla recently changed it's shell.js to support timezones without DST or in the southern hemisphere. https://bugzilla.mozilla.org/show_bug.cgi?id=836404
Steps to reproduce 1) Set time zone of your OS X to Sydney - Australia 2) run following code in Safari Developer console //Date '2014-10-05'is the first Sunday in October. It is date when DST is changing in Australia. var d = new Date(2014, 9, 5, 0, 0, 0, 0); // 2014-10-05 00:00:00 d.toString(); 3) see result in console Expexcted result: Sun Oct 05 2014 00:00:00 GMT+1000 (EST) Actual result: Sat Oct 04 2014 23:00:00 GMT+1000 (EST) Additional info: - APPLE BUG ID #13201479 - http://www.timeanddate.com/time/aboutdst.html - http://stackoverflow.com/questions/14839244/why-is-safari-confused-about-date-getday-for-dst-start-in-sydney-aus-time-zon - It is also reproducible with New Zealand time zone with different date. Affected date is date of DST change. Used software Safari 7.1, Safari 8.0
Daniel, could you please file a new bug about that? This is not necessarily the same as failing tests, which is essentially assumed to be a bug in those tests, not in JavaScriptCore.
(In reply to comment #22) > Daniel, could you please file a new bug about that? This is not necessarily the same as failing tests, which is essentially assumed to be a bug in those tests, not in JavaScriptCore. Ok, I have just created a new bug for it (Bug 137140).