Bug 4930 – Many JavaScriptCore date tests fail when timezone is not PDT

• Component: JavaScriptCore
• Status: REOPENED

[Mark Rowe (bdash)]

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

[Christopher Jerome]

(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]

Could we see some tests or examples?
fixed on r17444.

[Mark Rowe (bdash)]

Created attachment 11290 [details]
Output of run-javascriptcore-tests with r17446.

[Mark Rowe (bdash)]

The failing date tests all now appear to be off by one.

[Kevin McCullough]

fixed some tests, see r17520

[Kevin McCullough]

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

[Kevin McCullough]

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)]

*** Bug 16543 has been marked as a duplicate of this bug. ***

[Adam Roben (:aroben)]

*** Bug 24858 has been marked as a duplicate of this bug. ***

[Adam Roben (:aroben)]

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)]

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 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)]

*** Bug 19553 has been marked as a duplicate of this bug. ***

[Adam Roben (:aroben)]

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]

Oh sorry I was a little too quick there.

[Eric Seidel (no email)]

*** Bug 7998 has been marked as a duplicate of this bug. ***

[Patrick Mueller]

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]

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]

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]

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]

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]

(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).