<html>
    <head>
      <base href="https://bugs.webkit.org/" />
    </head>
    <body><span class="vcard"><a class="email" href="mailto:steve.hruda&#64;hexagongeospatial.com" title="Steve Hruda &lt;steve.hruda&#64;hexagongeospatial.com&gt;"> <span class="fn">Steve Hruda</span></a>
</span> changed
              <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Time zone bug"
   href="https://bugs.webkit.org/show_bug.cgi?id=137003">bug 137003</a>
        <br>
             <table border="1" cellspacing="0" cellpadding="8">
          <tr>
            <th>What</th>
            <th>Removed</th>
            <th>Added</th>
          </tr>

         <tr>
           <td style="text-align:right;">CC</td>
           <td>
               &nbsp;
           </td>
           <td>steve.hruda&#64;hexagongeospatial.com
           </td>
         </tr></table>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Time zone bug"
   href="https://bugs.webkit.org/show_bug.cgi?id=137003#c6">Comment # 6</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Time zone bug"
   href="https://bugs.webkit.org/show_bug.cgi?id=137003">bug 137003</a>
              from <span class="vcard"><a class="email" href="mailto:steve.hruda&#64;hexagongeospatial.com" title="Steve Hruda &lt;steve.hruda&#64;hexagongeospatial.com&gt;"> <span class="fn">Steve Hruda</span></a>
</span></b>
        <pre>Hi,
from my point of view, that's a regression because of the following changeset.
<a href="http://trac.webkit.org/changeset/159892">http://trac.webkit.org/changeset/159892</a>

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 -&gt; <a href="http://trac.webkit.org/browser/trunk/Source/WTF/wtf/DateMath.cpp?annotate=blame#L495">http://trac.webkit.org/browser/trunk/Source/WTF/wtf/DateMath.cpp?annotate=blame#L495</a>

But there are  two  additional lines -&gt;  497 &amp; 497 which fixes this special case…

if (diff &lt; 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(&quot;Sat Oct 25 2014 23:00:00 GMT+0200 (W. Europe Daylight Time)&quot;,
               (new Date(2014, 9, 25, 23, 0)).toString());
  assertEquals(&quot;Sat, 25 Oct 2014 21:00:00 GMT&quot;,
               (new Date(2014, 9, 25, 23, 0)).toUTCString());
  assertEquals(&quot;Sat Oct 25 2014 23:59:00 GMT+0200 (W. Europe Daylight Time)&quot;,
               (new Date(2014, 9, 25, 23, 59)).toString());
  assertEquals(&quot;Sat, 25 Oct 2014 21:59:00 GMT&quot;,
               (new Date(2014, 9, 25, 23, 59)).toUTCString());
  assertEquals(&quot;Sun Oct 26 2014 00:00:00 GMT+0200 (W. Europe Daylight Time)&quot;,
              (new Date(2014, 9, 26, 0, 0)).toString());
assertEquals(&quot;Sun Oct 26 2014 00:59:00 GMT+0200 (W. Europe Daylight Time)&quot;,
               (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(&quot;Sun Mar 30 2014 03:00:00 GMT+0200 (W. Europe Daylight Time)&quot;,
               (new Date(2014, 2, 30, 2, 0)).toString());
  assertEquals(&quot;Sun, 30 Mar 2014 01:00:00 GMT&quot;,
               (new Date(2014, 2, 30, 2, 0)).toUTCString());
  assertEquals(&quot;Sun Mar 30 2014 03:59:00 GMT+0200 (W. Europe Daylight Time)&quot;,
               (new Date(2014, 2, 30, 2, 59)).toString());
  assertEquals(&quot;Sun, 30 Mar 2014 01:59:00 GMT&quot;,
               (new Date(2014, 2, 30, 2, 59)).toUTCString());

Summer to winter time:
assertEquals(&quot;Sun Oct 26 2014 02:00:00 GMT+0200 (W. Europe Daylight Time)&quot;,
               (new Date(2014, 9, 26, 2, 0)).toString());
  assertEquals(&quot;Sun, 26 Oct 2014 00:00:00 GMT&quot;,
               (new Date(2014, 9, 26, 2, 0)).toUTCString());
  assertEquals(&quot;Sun Oct 26 2014 02:59:00 GMT+0200 (W. Europe Daylight Time)&quot;,
               (new Date(2014, 9, 26, 2, 59)).toString());
  assertEquals(&quot;Sun, 26 Oct 2014 00:59:00 GMT&quot;,
               (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</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>