Bug 137003 - Time zone bug
Summary: Time zone bug
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL: https://github.com/mbostock/d3/issues...
Keywords: InRadar
: 137140 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-09-22 08:31 PDT by Jason Davies
Modified: 2015-07-08 08:22 PDT (History)
11 users (show)

See Also:


Attachments
Patch which solves the midnight bug. (547 bytes, patch)
2015-06-29 09:02 PDT, Steve Hruda
no flags Details | Formatted Diff | Diff
V8DateTests.js (17.45 KB, application/javascript)
2015-06-29 09:03 PDT, Steve Hruda
no flags Details
Results before bug fix (1.49 KB, text/plain)
2015-06-29 09:07 PDT, Steve Hruda
no flags Details
Results after bug fix (918 bytes, text/plain)
2015-06-29 09:07 PDT, Steve Hruda
no flags Details
Patch which solves the midnight bug. (correct styling) (549 bytes, patch)
2015-06-30 10:33 PDT, Steve Hruda
ossy: review-
ossy: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jason Davies 2014-09-22 08:31:16 PDT
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
Comment 1 Alexey Proskuryakov 2014-09-30 14:47:43 PDT
*** Bug 137140 has been marked as a duplicate of this bug. ***
Comment 2 Alexey Proskuryakov 2014-09-30 14:48:34 PDT
Bug 137140 has some more details, including a finding that Australia is also affected.
Comment 3 Geoffrey Garen 2014-09-30 15:49:50 PDT
<rdar://problem/18507862>
Comment 4 damien 2014-10-05 15:21:02 PDT
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!
Comment 6 Steve Hruda 2015-06-29 09:00:36 PDT
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
Comment 7 Steve Hruda 2015-06-29 09:02:44 PDT
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
Comment 8 Steve Hruda 2015-06-29 09:03:12 PDT
Created attachment 255751 [details]
V8DateTests.js
Comment 9 Steve Hruda 2015-06-29 09:07:24 PDT
Created attachment 255752 [details]
Results before bug fix
Comment 10 Steve Hruda 2015-06-29 09:07:41 PDT
Created attachment 255753 [details]
Results after bug fix
Comment 11 WebKit Commit Bot 2015-06-30 10:22:49 PDT
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.
Comment 12 Steve Hruda 2015-06-30 10:33:12 PDT
Created attachment 255829 [details]
Patch which solves the midnight bug. (correct styling)
Comment 13 Csaba Osztrogonác 2015-07-08 08:22:04 PDT
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 )