REOPENED 4930
Many JavaScriptCore date tests fail when timezone is not PDT 
https://bugs.webkit.org/show_bug.cgi?id=4930
Summary Many JavaScriptCore date tests fail when timezone is not PDT
Mark Rowe (bdash)
Reported 2005-09-11 01:21:13 PDT
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
Attachments
Output of run-javascriptcore-tests with r17446. (122.77 KB, text/html)
2006-10-30 14:54 PST, Mark Rowe (bdash) 		no flags
Details
patch to force time zone to PST8PDT when running tests (2.50 KB, patch)
2009-03-26 14:30 PDT, Adam Roben (:aroben) 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Christopher Jerome
Comment 1 2006-01-06 16:34:42 PST
(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.
Kevin McCullough
Comment 2 2006-10-30 13:42:22 PST
Could we see some tests or examples? fixed on r17444.
Mark Rowe (bdash)
Comment 3 2006-10-30 14:54:15 PST
Created attachment 11290 [details] Output of run-javascriptcore-tests with r17446.
Mark Rowe (bdash)
Comment 4 2006-10-30 14:55:08 PST
The failing date tests all now appear to be off by one.
Kevin McCullough
Comment 5 2006-11-01 12:44:07 PST
fixed some tests, see r17520
Kevin McCullough
Comment 6 2006-11-01 12:47:33 PST
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
digdog
Comment 7 2006-12-08 08:06:35 PST
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
Kevin McCullough
Comment 8 2006-12-08 11:07:16 PST
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.
Mark Rowe (bdash)
Comment 9 2007-12-20 14:31:08 PST
*** Bug 16543 has been marked as a duplicate of this bug. ***
Adam Roben (:aroben)
Comment 10 2009-03-26 14:29:17 PDT
*** Bug 24858 has been marked as a duplicate of this bug. ***
Adam Roben (:aroben)
Comment 11 2009-03-26 14:30:18 PDT
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?
Adam Roben (:aroben)
Comment 12 2009-03-26 14:39:47 PDT
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)");
Adam Roben (:aroben)
Comment 13 2009-03-26 14:52:30 PDT
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.
Eric Seidel (no email)
Comment 14 2009-05-17 23:42:35 PDT
*** Bug 19553 has been marked as a duplicate of this bug. ***
Adam Roben (:aroben)
Comment 15 2009-05-18 11:58:27 PDT
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.
Kevin McCullough
Comment 16 2009-05-18 12:01:21 PDT
Oh sorry I was a little too quick there.
Eric Seidel (no email)
Comment 17 2009-12-06 23:33:00 PST
*** Bug 7998 has been marked as a duplicate of this bug. ***
Patrick Mueller
Comment 18 2009-12-10 09:02:18 PST
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
Fumitoshi Ukai
Comment 19 2010-01-12 19:47:33 PST
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.
Lauro Moura Maranhao Neto
Comment 20 2013-06-11 14:02:30 PDT
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
Daniel Herbolt
Comment 21 2014-09-25 03:08:33 PDT
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
Alexey Proskuryakov
Comment 22 2014-09-25 09:05:13 PDT
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.
Daniel Herbolt
Comment 23 2014-09-25 22:46:16 PDT
(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).
Note You need to log in before you can comment on or make changes to this bug.