[Webkit-unassigned] [Bug 137003] Time zone bug

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=137003

Steve Hruda <steve.hruda at hexagongeospatial.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |steve.hruda at hexagongeospati
                   |                            |al.com

--- Comment #6 from Steve Hruda <steve.hruda at hexagongeospatial.com> ---
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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150629/1096d77c/attachment.html>