new Date() object when it comes to daylight savings time lines -- 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 still relying on 'unix time'.
My Research; the closest questions to my issue:
- This user was working on the particular hours right around the DST change.
- This user was worried about the presentation of the time depending on the user's time zone. The accepted answer on that page mentioned that
getTimezoneOffset is "flaky" which led me to not delve into that.
- See my answer below on other questions that have some great insights
Eastern Time (US & Canada) and check the 'Automatically adjust clock for Daylight Saving Time'.
The two languages results' come back into agreement on 11/06/2006!
I have tried to simplify this as much as possible but there are still quite a few gears in motion.
1) Here is the PHP code and output that shows the CORRECT number of milliseconds until the date 11/01/2006.
echo "Unixtime for November 1, 2006 is: ".strtotime("11/01/2006")."\n";
echo "Unixtime for November 6, 2006 is: ".strtotime("11/06/2006");
The result is:
Unixtime for November 1, 2006 is: 1162357200 (where the disagreement lies)
Unixtime for November 6, 2006 is: 1162789200
Both of them are based off of GMT-0500.
new Date and then
getTime() upon it like so (and remove the milliseconds):
This generates the values
1162353600 <-- PHP outputs: 1162357200
1162789200 <-- the same as PHP for '2006/11/06'; congruence is restored
which is a difference (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. (see more explanation of my particular scenario)
Date("2006/11/01") without calling
My jsfiddle** experiment (also listed above) shows these results.
**(you may need to change your computer's timezone to see the identical behavior).
Possibly coming into play is that according to Wikipedia 2006 was the first year that Indiana began using DST. A curious puzzle either way.
Notably, on this iMac I did not force the timezone and I'm not sure this Apple computer would allow it. The settings for "Set date and time automatically" was checked (
disabled. The time zone was set to Eastern Daylight Time. The box to 'Set timezone automatically' was unchecked (
I added the
Windows tag to highlight that it doesn't seem to be a problem in OSX.
Update: According to the site linked above, I verified that all the following dates crossed into a new GMT offset on the appropriate dates (updated fiddle) -- unlike how the 2006 response was one week off. I.e., on November 4th, 2007, it was
GMT-4 and November 5th, 2007, it returned
- 2007 Sunday, March 11 at 2:00 AM Sunday, November 4 at 2:00 AM
- 2008 Sunday, March 9 at 2:00 AM Sunday, November 2 at 2:00 AM
- 2009 Sunday, March 8 at 2:00 AM Sunday, November 1 at 2:00 AM
- 2010 Sunday, March 14 at 2:00 AM Sunday, November 7 at 2:00 AM
- 2011 Sunday, March 13 at 2:00 AM Sunday, November 6 at 2:00 AM
Firstly, time in Indiana is very complicated.
TimeZoneInfo class 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);
(So it knows it's not in daylight saving time then.)
Likewise in Noda Time (my own date and time library, which uses the tzdb database):
var zone = DateTimeZone.ForId("America/Indiana/Indianapolis");
var instant = new Instant(1162357200 * NodaConstants.TicksPerSecond);
var zoned = new ZonedDateTime(instant, zone);
Local: 01/11/2006 00:00:00 Offset: -05 Zone: America/Indiana/Indianapolis