Note that there are some explanatory texts on larger screens.

plurals
  1. POjavascript incorrectly determines daylight savings time line -- an example out of 2006
    text
    copied!<p>I have read many StackOverflow questions on the javascript <code>new Date()</code> object when it comes to daylight savings time <em>lines</em> -- as in when they are crossed. However, I haven't seen an answer about this particular problem or a way to work around it while <em>still relying</em> on 'unix time'.</p> <p>I have personally chosen to work around this issue by passing the javascript date as a date to my PHP code rather than the unix time. Yet, the nagging question still remains! I have confirmed this behavior on IE8, Chrome, and FF so I'm assuming it will behave the same for you. (<strong>Update:</strong> OSX users might <em>not</em> be able to generate this behavior)</p> <p>My Research; the closest questions to my issue:</p> <ul> <li><a href="https://stackoverflow.com/questions/4018320/javascript-date-objects-and-daylight-savings-time">This user</a> was working on the particular hours right around the DST change.</li> <li><a href="https://stackoverflow.com/questions/9543580/javascript-time-zones-and-daylight-savings-time">This user</a> was worried about the presentation of the time depending on the user's time zone. The accepted answer on that page mentioned that <code>getTimezoneOffset</code> is "flaky" which led me to not delve into that.</li> <li>See my answer below on other questions that have some great insights</li> </ul> <p>I have generated a test scenario around November 1st, 2006. This may or may not work the same for you depending on the time zone you are in. If I understand the javascript aspect correctly, you will need to synchronize your PC's clock to </p> <blockquote> <p>Eastern Time (US &amp; Canada) and check the 'Automatically adjust clock for Daylight Saving Time'.</p> </blockquote> <p>I am basing this experiment off of the "Indianapolis" time zone in PHP. My javascript result, when I find the unix time for November 1st, 2006 is <strong>one hour off</strong> of what the PHP generates (3600 seconds). According to <a href="http://timeanddate.com/worldclock/timezone.html?n=105&amp;syear=2000" rel="nofollow noreferrer">this page</a> (Thanks Jon!) javascript is wrong.</p> <p>The two languages results' come <strong>back into agreement</strong> on 11/06/2006!</p> <p>This and other research causes me to believe that Javascript got its history wrong and picked the wrong Sunday to 'Fall back' out of DST -- thereby causing the discrepancy I am seeing.</p> <p>I have tried to simplify this as much as possible but there are still quite a few gears in motion.</p> <p>1) <a href="http://ideone.com/lSd9C" rel="nofollow noreferrer">Here is the PHP code and output</a> that shows the CORRECT number of milliseconds until the date 11/01/2006.</p> <pre><code>date_default_timezone_set("America/Indiana/Indianapolis"); echo "Unixtime for November 1, 2006 is: ".strtotime("11/01/2006")."\n"; echo "Unixtime for November 6, 2006 is: ".strtotime("11/06/2006"); </code></pre> <p>The result is:</p> <pre><code>Unixtime for November 1, 2006 is: 1162357200 (where the disagreement lies) Unixtime for November 6, 2006 is: 1162789200 </code></pre> <p>Both of them are based off of GMT-0500.</p> <p>2) In Javascript, (see my <a href="http://jsfiddle.net/xpZeY/5/" rel="nofollow noreferrer">jsfiddle</a>**), I call <code>new Date</code> and then <code>getTime()</code> upon it like so (and remove the milliseconds):</p> <pre><code>new Date("2006/11/01").getTime()/1000 new Date("2006/11/06").getTime()/1000 </code></pre> <p>This generates the values</p> <pre><code>1162353600 &lt;-- PHP outputs: 1162357200 1162789200 &lt;-- the same as PHP for '2006/11/06'; congruence is restored </code></pre> <p>which is a <em>difference</em> (for 2006/11/01) from the output via PHP of 3600 seconds -- or one hour. This value (one hour earlier) when processed in my PHP application generated the prior day (2006/10/31) which was unacceptable since it broke my navigation forward. (<a href="http://chat.stackoverflow.com/transcript/message/3640316#3640316">see more explanation of my particular scenario</a>)</p> <p>Outputting in Javascript: <code>Date("2006/11/01")</code> without calling <code>getTime()</code> clears up some of the mystery because javascript reveals the offset it was using <code>GMT-0400</code>.</p> <p>My <a href="http://jsfiddle.net/xpZeY/5/" rel="nofollow noreferrer">jsfiddle</a>** experiment (also listed above) shows these results.</p> <p>**(you may need to change your computer's timezone to see the identical behavior).</p> <p>Possibly coming into play is that <a href="https://en.wikipedia.org/wiki/Daylight_saving_time_in_the_United_States#Indiana" rel="nofollow noreferrer">according to Wikipedia 2006 was the first year that Indiana</a> began using DST. A curious puzzle either way.</p> <p>Since I have already worked out my solution (by avoiding relying on unix time in my javascript) I thought I should post this for posterity and hopefully someone might know how to correct the value javascript is showing.</p> <p><strong>The question is this:</strong> How does one bring the two 'unix time' results between PHP and javascript into alignment? I would be grateful to learn how around the DST 'line' or in general. (I'm currently assuming the DST line is the problem).</p> <p><strong>Update:</strong> an iMac running Chrome generated the results that PHP is generating. What??? Wild. Any javascript-side fix to this behavior looks like it would be a great undertaking (or at least ugly). Perhaps this <em>is not</em> a javascript problem since it generates the correct answer depending on the OS (or other factors?).</p> <p>Notably, on this iMac I <strong>did not</strong> force the timezone and I'm not sure this Apple computer would allow it. The settings for "Set date and time automatically" was checked (<code>true</code>) and <code>disabled</code>. The time zone was set to Eastern Daylight Time. The box to 'Set timezone automatically' was unchecked (<code>false</code>) and <code>disabled</code>.</p> <p>I added the <code>Windows</code> tag to highlight that it doesn't seem to be a problem in OSX.</p> <p><strong>Update:</strong> According to the site <a href="http://timeanddate.com/worldclock/timezone.html?n=105&amp;syear=2000" rel="nofollow noreferrer">linked above</a>, I verified that <a href="http://jsfiddle.net/xpZeY/7/" rel="nofollow noreferrer">all the following dates crossed into a new GMT offset on the appropriate dates (updated fiddle)</a> -- unlike how the 2006 response was <em>one week off</em>. I.e., on November 4th, 2007, it was <code>GMT-4</code> and November 5th, 2007, it returned <code>GMT-5</code>.</p> <ul> <li>2007 Sunday, March 11 at 2:00 AM Sunday, November 4 at 2:00 AM</li> <li>2008 Sunday, March 9 at 2:00 AM Sunday, November 2 at 2:00 AM</li> <li>2009 Sunday, March 8 at 2:00 AM Sunday, November 1 at 2:00 AM</li> <li>2010 Sunday, March 14 at 2:00 AM Sunday, November 7 at 2:00 AM</li> <li>2011 Sunday, March 13 at 2:00 AM Sunday, November 6 at 2:00 AM</li> </ul> <p>Lastly, if you know the proper channels to submit this error in 2006 to whatever timezone source Javascript is relying on, please do so and let me know about it.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload