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
*** Bug 137140 has been marked as a duplicate of this bug. ***
Bug 137140 has some more details, including a finding that Australia is also affected.
<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!
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
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
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
Created attachment 255751 [details] V8DateTests.js
Created attachment 255752 [details] Results before bug fix
Created attachment 255753 [details] Results after bug fix
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.
Created attachment 255829 [details] Patch which solves the midnight bug. (correct styling)
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 )