Bug 4930 - Many JavaScriptCore date tests fail when timezone is not PDT
Summary: Many JavaScriptCore date tests fail when timezone is not PDT
Status: REOPENED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P2 Normal
Assignee: Kevin McCullough
URL:
Keywords:
: 7998 16543 19553 24858 (view as bug list)
Depends on:
Blocks: 7998
  Show dependency treegraph
 
Reported: 2005-09-11 01:21 PDT by Mark Rowe (bdash)
Modified: 2014-09-25 22:46 PDT (History)
14 users (show)

See Also:


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 Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Rowe (bdash) 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
Comment 1 Christopher Jerome 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.
Comment 2 Kevin McCullough 2006-10-30 13:42:22 PST
Could we see some tests or examples?
fixed on r17444.
Comment 3 Mark Rowe (bdash) 2006-10-30 14:54:15 PST
Created attachment 11290 [details]
Output of run-javascriptcore-tests with r17446.
Comment 4 Mark Rowe (bdash) 2006-10-30 14:55:08 PST
The failing date tests all now appear to be off by one.
Comment 5 Kevin McCullough 2006-11-01 12:44:07 PST
fixed some tests, see r17520
Comment 6 Kevin McCullough 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
Comment 7 digdog 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
Comment 8 Kevin McCullough 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.
Comment 9 Mark Rowe (bdash) 2007-12-20 14:31:08 PST
*** Bug 16543 has been marked as a duplicate of this bug. ***
Comment 10 Adam Roben (:aroben) 2009-03-26 14:29:17 PDT
*** Bug 24858 has been marked as a duplicate of this bug. ***
Comment 11 Adam Roben (:aroben) 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?
Comment 12 Adam Roben (:aroben) 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)");
Comment 13 Adam Roben (:aroben) 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.
Comment 14 Eric Seidel (no email) 2009-05-17 23:42:35 PDT
*** Bug 19553 has been marked as a duplicate of this bug. ***
Comment 15 Adam Roben (:aroben) 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.
Comment 16 Kevin McCullough 2009-05-18 12:01:21 PDT
Oh sorry I was a little too quick there.
Comment 17 Eric Seidel (no email) 2009-12-06 23:33:00 PST
*** Bug 7998 has been marked as a duplicate of this bug. ***
Comment 18 Patrick Mueller 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
Comment 19 Fumitoshi Ukai 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.
Comment 20 Lauro Moura Maranhao Neto 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
Comment 21 Daniel Herbolt 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
Comment 22 Alexey Proskuryakov 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.
Comment 23 Daniel Herbolt 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).