Javascript incorrectly defines daylight saving time - 2006 example

Question

I read a lot of StackOverflow questions on the javascript new Date() object when it comes to daylight saving time lines - like when crossing. However, I did not see an answer about this particular problem or a way around it, still relying on "unix time".

I personally decided to work around this problem by passing the javascript date as the date for my PHP code, not the unix time. However, the grumbling question still remains! I have confirmed this behavior in IE8, Chrome and FF, so I assume that it will behave the same for you. ( Update: OSX users may not generate this behavior)

My research; closest questions to my problem:

• This user worked on a specific watch right around the DST change.
• This user was worried about the time representation depending on the user's time zone. The accepted answer on this page mentioned that getTimezoneOffset is "flaky", which caused me not to delve into it.
• See my answer below for other questions that contain some great ideas.

I created a test case around November 1, 2006. This may or may not work the same for you, depending on what time zone you are in. If I understand the javascript aspect correctly, you will need to synchronize your PC clock to

Eastern time (USA and Canada) and check the box "Automatically set the clock for daylight saving time."

I base this experiment on the Indianapolis timezone in PHP. My javascript result is when I find that the unix time on November 1, 2006 is one hour of what PHP is generating (3600 seconds). According to this page (thanks Jon!) Javascript is incorrect.

The results of the two languages ​​are returned back to the agreement 06/11/2006!

This and other studies make me believe that Javascript misunderstood its story and chose the wrong Sunday to “backtrack” from the DST, thereby causing the inconsistency that I see.

I tried to simplify this as much as possible, but there are a few more gears in motion.

1) Here is the PHP code and the output , which shows the CORRECT number of milliseconds before the date 11/01/2006.

 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"); 

Result:

 Unixtime for November 1, 2006 is: 1162357200 (where the disagreement lies) Unixtime for November 6, 2006 is: 1162789200 

Both are based on GMT-0500.

2) In Javascript (see my jsfiddle **), I call new Date and then getTime() on it (and delete the milliseconds):

 new Date("2006/11/01").getTime()/1000 new Date("2006/11/06").getTime()/1000 

It generates values

 1162353600 <-- PHP outputs: 1162357200 1162789200 <-- the same as PHP for '2006/11/06'; congruence is restored 

which is the difference (for 2006/11/01) from exiting through PHP 3600 seconds - or one hour. This value (an hour earlier) when processing my PHP application generated the previous day (2006/10/31), which was unacceptable, since it disrupted my navigation forward. ( see a more detailed description of my specific scenario )

The output in Javascript: Date("2006/11/01") without calling getTime() clears some secrets because javascript shows the offset that it used GMT-0400 .

My jsfiddle ** experiment (also listed above) shows these results.

** (you may need to change the time zone of your computer to see identical behavior).

Perhaps the entry into the game is that according to Wikipedia 2006 was the first year Indiana started using DST. A curious puzzle anyway.

Since I already developed my solution (avoiding relying on unix time in my javascript), I thought I should post it for posterity and hopefully someone can know how to fix the javascript value.

The question is:. How can you bring the two unix time results between PHP and javascript into alignment? I would appreciate to know how around DST 'line' or in general. (I currently assume that the DST line is a problem).

Update: iMac working with Chrome generates the results that PHP generates. What kind??? Wild. Any javascript-side related fix seems to be a great event (or at least ugly). Perhaps this is not a problem with javascript, as it generates the correct answer depending on the OS (or other factors?).

It is noteworthy that on this iMac I did not have to force the time zone, and I'm not sure that this Apple computer will allow this. The settings "Set date and time automatically" ( true ) and disabled were noted. The time zone was set to Eastern Daylight Time. The "Set time zone automatically" ( false ) and disabled .

I added a Windows tag to emphasize that this does not seem to be a problem in OSX.

Update: In accordance with the site linked above , I confirmed that all of the following dates intersect in the new GMT offset for the corresponding dates (updated fiddle) - unlike the 2006 response for a week. Ie, November 4, 2007, he was GMT-4 and November 5, 2007, he returned GMT-5 .

• 2007 Sunday, March 11 at 2:00 a.m. Sunday, November 4 at 2:00 a.m.
• 2008 Sunday, March 9 at 2:00 a.m. Sunday, November 2 at 2:00 a.m.
• 2009 Sunday, March 8 at 2:00 on Sundays, November 1 at 2:00.
• 2010 Sunday, March 14 at 2:00 a.m. Sunday, November 7 at 2:00 a.m.
• 2011 Sunday, March 13 at 2:00 on Sundays, November 6 at 2:00.

Finally, if you know the correct channels to send this error in 2006 to any time source referenced by Javascript, do this and let me know.

Answer 1

Firstly, time in Indiana is very difficult .

But in this case, I believe that Javascript is wrong. The output of your Javascript on my machine (setting the time zone) - "Wed Nov 01 2006 00:00:00 GMT-0400 (Eastern Daylight Time)" on Chrome and "Wed Nov 1 00:00:00 EDT 2006" in Internet Explorer - but daylight saving time ended in Indianapolis in 2006 on October 29th .

Class

.NET TimeZoneInfo gives the same result:

 // Ignore the daft ID; it really means Eastern time var zone = TimeZoneInfo.FindSystemTimeZoneById("Eastern Standard Time"); var local = new DateTime(2006, 11, 1); Console.WriteLine(zone.GetUtcOffset(local)); 

Conclusion:

 -5:00:00 

(So ​​he doesn’t know this in the summer.)

Similarly in Noda Time (my own date and time library that uses the tzdb database):

 var zone = DateTimeZone.ForId("America/Indiana/Indianapolis"); var instant = new Instant(1162357200 * NodaConstants.TicksPerSecond); var zoned = new ZonedDateTime(instant, zone); Console.WriteLine(zoned); 

Result:

 Local: 01/11/2006 00:00:00 Offset: -05 Zone: America/Indiana/Indianapolis 

Answer 2

Phew; I think John has some great points and evidence that Javascript was pulling the wrong database on Windows machines when daylight saving time began - at least in Indiana - at the beginning of the week of November 2006.

I still don’t know exactly how I will solve this dilemma in Javascript. However, since my main issue was the “mismatch” between Javascript and PHP (after all, if they changed to DST on the same day / at the same hour, I would never have noticed that there was a problem), the solution is probably should stop relying on one or the other.

This SO answer , without extracting unixtime, demonstrates how I can solve this problem if I need to continue to rely on unixtime. This is actually a pretty smooth solution, IMHO. Overview: Get time zone information through AJAX. This would mean that PHP would always settle for unixtime at 00:00:00 on any given day, as it would essentially provide value.

However, this still doesn't seem like a real solution to the problem: Javascript gets the wrong idea when the Eastern time zone came out of daylight saving time. Anyway, I would be grateful for how this extremely small and narrow window of inconsistency could be corrected.

Could it even be complicated, like a "probably not yet developed" Windows patch, since the OSX machine I was experimenting with was displaying the correct values ​​in Javascript?

I doubt my scenario and this question are related, but this is an exciting mistake that I encountered during the research. In this question, a Date object - depending on the format passed in - can generate some really amazing results.

If someone wanted to undermine the trust in the time zone of the db user computer to calculate the correct date, this answer may be of some help in cooking and rely on their own timezone databases. I have not researched working with such a solution and how to override the unixtime result returned by Javascript, but this is the closest answer I found. I wonder what overhead would be ...? Be sure to submit an answer if you can implement this type of solution - this will probably be the true answer to my original question.