Time zone bug

• Component: JavaScriptCore
• Status: NEW ---

[Jason Davies]

It looks like there's a bug with time zone handling:

> new Date(2014, 8, 27, 14)
< Sat Sep 27 2014 13:00:00 GMT+1200 (NZST)

The DST change doesn't happen until 2am the next day.  Notice that the offset is +1200 for any times on the 27th, whereas it correctly switches to +1300 on the Sunday:

> new Date(2014, 8, 28, 3)
< Sun Sep 28 2014 03:00:00 GMT+1300 (NZDT)

By the way, it's interesting that the DST offset occurs at 2014-09-27T14:00:00Z (UTC) - maybe there's been a mixup here.

First reported here: https://github.com/mbostock/d3/issues/2028

[Alexey Proskuryakov]

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

[Alexey Proskuryakov]

Bug 137140 has some more details, including a finding that Australia is also affected.

[Geoffrey Garen]

<rdar://problem/18507862>

It is probably worth mentioning that this break has some significant implications, as you can actually end up with the wrong date:

> new Date("October 5, 2014")
< Sat Oct 04 2014 23:00:00 GMT+1000 (AEST)

> new Date("2014/10/05")
< Sat Oct 04 2014 23:00:00 GMT+1000 (AEST)

> new Date("2014-10-05")
< Sun Oct 05 2014 11:00:00 GMT+1100 (AEDT)

It looks like the 'usual' ways to a javascript date for Sunday, October 5 in AEDT/AEST in Safari give the wrong result. (NZST as well?)

I booked movie tickets for the wrong day!

[Daniel Herbolt]

Similar bugs in Chrome and Firefox:
https://code.google.com/p/chromium/issues/detail?id=425434
https://bugzilla.mozilla.org/show_bug.cgi?id=1084434

[Steve Hruda]

Hi,
from my point of view, that's a regression because of the following changeset.
http://trac.webkit.org/changeset/159892

This changeset doesn't handles extrem values like midnight, where the offsetHour of the UTC time is 23 (one day before) and the local time is 1 o'clock (next day)

In case of all other OS systems you will see the same code -> http://trac.webkit.org/browser/trunk/Source/WTF/wtf/DateMath.cpp?annotate=blame#L495

But there are  two  additional lines ->  497 & 497 which fixes this special case…

if (diff < 0)
        diff += secondsPerDay;


That means …. 

localSystemTime.wHour = 0;
offsetHour=23 … which causes a negative value … and the diff+=secondsPerDay ensures that the diff result would be one Hour instead of -23 hours

We’ve found the attached V8DateTests.js (renamed to .txt) and adjusted it a little bit to get the results logged in the browsers console.
As you can see at “ResulBeforeOurBugFix.txt” and “ResultAfterOurBugFix.txt”, we were able to fix 6 tests which failed before out bug fix. 

assertEquals("Sat Oct 25 2014 23:00:00 GMT+0200 (W. Europe Daylight Time)",
               (new Date(2014, 9, 25, 23, 0)).toString());
  assertEquals("Sat, 25 Oct 2014 21:00:00 GMT",
               (new Date(2014, 9, 25, 23, 0)).toUTCString());
  assertEquals("Sat Oct 25 2014 23:59:00 GMT+0200 (W. Europe Daylight Time)",
               (new Date(2014, 9, 25, 23, 59)).toString());
  assertEquals("Sat, 25 Oct 2014 21:59:00 GMT",
               (new Date(2014, 9, 25, 23, 59)).toUTCString());
  assertEquals("Sun Oct 26 2014 00:00:00 GMT+0200 (W. Europe Daylight Time)",
              (new Date(2014, 9, 26, 0, 0)).toString());
assertEquals("Sun Oct 26 2014 00:59:00 GMT+0200 (W. Europe Daylight Time)",
               (new Date(2014, 9, 26, 0, 59)).toString());

In addition we found out that WebKit also have problems in case of Windows in case of the change from winter to summer time.

Winter to summer time:
assertEquals("Sun Mar 30 2014 03:00:00 GMT+0200 (W. Europe Daylight Time)",
               (new Date(2014, 2, 30, 2, 0)).toString());
  assertEquals("Sun, 30 Mar 2014 01:00:00 GMT",
               (new Date(2014, 2, 30, 2, 0)).toUTCString());
  assertEquals("Sun Mar 30 2014 03:59:00 GMT+0200 (W. Europe Daylight Time)",
               (new Date(2014, 2, 30, 2, 59)).toString());
  assertEquals("Sun, 30 Mar 2014 01:59:00 GMT",
               (new Date(2014, 2, 30, 2, 59)).toUTCString());

Summer to winter time:
assertEquals("Sun Oct 26 2014 02:00:00 GMT+0200 (W. Europe Daylight Time)",
               (new Date(2014, 9, 26, 2, 0)).toString());
  assertEquals("Sun, 26 Oct 2014 00:00:00 GMT",
               (new Date(2014, 9, 26, 2, 0)).toUTCString());
  assertEquals("Sun Oct 26 2014 02:59:00 GMT+0200 (W. Europe Daylight Time)",
               (new Date(2014, 9, 26, 2, 59)).toString());
  assertEquals("Sun, 26 Oct 2014 00:59:00 GMT",
               (new Date(2014, 9, 26, 2, 59)).toUTCString());


The attached DateMath.cpp.patch solves the first issue. The extrem value bug, winter to summer and summer to winter time is still open.

Regards,
Steve

[Steve Hruda]

Created attachment 255750 [details]
Patch which solves the midnight bug.

new Date('2015-06-09T22:00:00.000Z').getTimezoneOffset()
should return -120 in case of the following timezone 
     (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna
but it returns 1320

[Steve Hruda]

Created attachment 255751 [details]
V8DateTests.js

[Steve Hruda]

Created attachment 255752 [details]
Results before bug fix

[Steve Hruda]

Created attachment 255753 [details]
Results after bug fix

[WebKit Commit Bot]

Attachment 255750 [details] did not pass style-queue:


ERROR: Source/WTF/wtf/DateMath.cpp:483:  Tab found; better to use spaces  [whitespace/tab] [1]
ERROR: Source/WTF/wtf/DateMath.cpp:484:  When wrapping a line, only indent 4 spaces.  [whitespace/indent] [3]
ERROR: Source/WTF/wtf/DateMath.cpp:485:  Tab found; better to use spaces  [whitespace/tab] [1]
Total errors found: 3 in 1 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Steve Hruda]

Created attachment 255829 [details]
Patch which solves the midnight bug. (correct styling)

[Csaba Osztrogonác]

Comment on attachment 255829 [details]
Patch which solves the midnight bug. (correct styling)

Please add changelog entry and new test cases which cover this bug.
( http://www.webkit.org/coding/contributing.html )