Daylight savings time does not depend only on geographic location

[brendan]

See Mozilla bug 365349 (https://bugzilla.mozilla.org/show_bug.cgi?id=365349). Thanks to U.S. Representative Ed Markey, the U.S. is about to enter Daylight Savings Time this weekend, three weeks early compared to last year. ES1-3 all say that DST computation depends on only four data:

• the time since the beginning of the year,
• whether t is in a leap year,
• the week day of the beginning of the year, and
• the geographic location.

This design, from my memory, assumed a more sane and stable DST regime. So according to the spec, I should find that noon on March 12, 2006 was in DST, just because noon this coming Monday is in DST. This is crazy, and of course all the browser engines rely on the OS for DST information, which AFAIK will be historically accurate. We should do something in ES4 to conform to the de facto standard thereby created by OS-based browser Data implementations. Comments?

[lth]

I agree that we should fix this.

What are the bugs in the current specs?

• "Geographic location" is implicit: it is in practice tied to the computer running the code. On the web this is not particularly right or wrong, it would be no worse to tie it to the computer serving the site, in many cases. The spec might be more explicit about this.

• "Geographic location" is shorthand for "current political situation at the geographic location chosen for DST adjustment".

I think the spec should punt and say that DaylightSavingsTA(t) returns a best effort value for the daylight savings adjustment for the UTC timestamp t at the location of the computer running the code; with an imprecation to use historical data when relevant and possible.

[David-Sarah Hopwood]

Latest ES3.1 draft still has this bug (in section 15.9.1.7), and it should be fixed.