tags:

views:

102

answers:

2

"During the "energy crisis" years, Congress enacted earlier starting dates for daylight time. In 1974, daylight time began on 6 January and in 1975 it began on 23 February. After those two years the starting date reverted back to the last Sunday in April. "
(via http://aa.usno.navy.mil/faq/docs/daylight_time.php )

There appears to be a bug in the Javascript date object for these dates. If you convert 127627200000 milliseconds to a date, it should be Thu Jan 17 00:00:00 EDT 1974. This is correct on http://www.fileformat.info/tip/java/date2millis.htm, but incorrect on http://www.esqsoft.com/javascript_examples/date-to-epoch.htm, which says it converts to Wed Jan 16 1974 23:00:00 GMT-0500 (Eastern Standard Time). If you create a new Date(127627200000) object in javascript, it gives the latter date conversion. This happens in all major browsers.

I can't imagine this is first time this has been a problem for anyone, but I can't find any other cases of this problem with a few searches online. Does anyone know if there is an existing fix for this or an easier fix than manually checking the dates Javascript has the conversion wrong? Are there other dates this is a problem?

A: 

Java does historical time zones (back to about 1920), JavaScript apparently does not.

Mark Thornton
+5  A: 

As ever, it's best to check the spec :)

In this case, I was pretty shocked to see this in section 15.9.1.9 of ECMA-262:

The implementation of ECMAScript should not try to determine whether the exact time was subject to daylight saving time, but just whether daylight saving time would have been in effect if the current daylight saving time algorithm had been used at the time. This avoids complications such as taking into account the years that the locale observed daylight saving time year round.

In other words, a conformant ECMAScript implementation is not allowed to be historically accurate.

Now whether all implementations follow this or not, I'm not sure... but it does suggest you'd need some kind of separate library if you wanted to get historically accurate time zones... where "historically accurate" doesn't have to be nearly as far back as 1974, of course: the US changed its DST schedule in 2007, and other countries have done so more recently than that (and with less warning).


1 The first occurrence of 15.9.1.9. For some reason it occurs twice - once for "Daylight Saving Time Adjustment" and once for "Local Time". Wow.

Jon Skeet
Java's historical time zones have surprised quite a few people (especially when they were added in 1.4). Particular surprises are the +1 hour offset for London at 1970-01-01 and the fractional second offsets for Greece, Helsinki in the early 1920's.
Mark Thornton
Fractional second offsets do indeed sound like bad news. I think I'd even argue that so few applications would really *want* that behaviour, it might be best to leave it out, like leap seconds...
Jon Skeet