** Request **
Instead of constraining timezone offset behaviour as in 15.9.1.8, the spec should leave DaylightSavingsTA implementation dependent.
** Issue **
The current spec text in 15.9.1.8 allows implementations to be as wrong as they'd like about daylight savings adjustments, but constrains how correct they should try to be. This is somewhat counterintuitive, and in practice, has not succeeded in producing consensus between browsers.
For example - here are browser results for a few dates in the US Pacific timezone:
new Date("4/1/2000").getTimezoneOffset()
Windows Debian Mac
IE CH FF OP SF Node Node CH FF SF
4/1/2000 420 420 420 420 420 420 480 480 480 420
Note that on this date Chrome, FireFox and Node are inconsistent between OSes. Almost everyone is actually wrong though, the actual DST adjustment was 480.
4/1/2028 420 420 420 420 420 420 420 420 420 420
Note that on this date, everyone is consistent, and correct, but Chrome on Mac and Firefox on Mac are violating the ES5.1 spec (both 2000 and 2028 are leap years starting on a Saturday)
3/10/2011 480 480 480 480 480 480 480 480 480 480
3/10/2109 480 480 480 480 420 480 480 480 420 420
Note that on this date, a few environments are again violating ES5.1 rules (these two years both start on Tuesday and are not leap years), but here there are disagreements even on a single OS (both on Windows and Mac).
In IE10, we are expecting to change our behaviour for 4/1/2000 above to be historically correct, match Chrome and Firefox on Mac and Node on Debian, and violate the current ES5.1 spec text constraints.
The second issue is with host APIs that provide Date objects to JavaScript code. For example - the File.lastModifiedDate from the W3C File API [1]. If the OS reports in its file browser that a file was modified on 3/31/2000 at 11PM, JavaScript will report that the file was modified on 4/1/2000 at 12AM when run on the same system. With an increasing number of host APIs exposing access to host OS resources like filesystems, and opportunities to round trip Date objects between host APIs and JavaScript, both in browser hosts and server hosts, this disconnect will get increasingly serious for JavaScript application reliability.
** Recommendation **
I would love to be able to solve this by specifying DaylightSavingsTA more fully and requiring implementations to be more correct, but this is not a realistic option as there is no oracle of truth on timezone adjustments. Given that browsers are already inconsistent on timezone adjustment behaviour, there is limited value in trying to prevent implementations from at least being historically correct when they can.
Instead of constraining timezone offset behaviour as in 15.9.1.8, the spec should leave DaylightSavingsTA implementation dependent.
[0] http://www.w3.org/International/wiki/JavaScriptInternationalization
[1] http://www.w3.org/TR/FileAPI/#dfn-lastModifiedDate
See also Norbert's mail response about how this relates to text in the Internationalization spec.
https://mail.mozilla.org/pipermail/es-discuss/2012-March/020832.html
ES2015 contains language allowing DaylightSavingsTA to be implementation dependent.