I raised some concerns about the current ES5.1 spec rules for daylight savings
handling (15.9.1.8) with a few folks at recent TC39 f2f meetings. Norbert also
raise similar concerns in reviewing issues related to globalization APIs, and
in notes on internationalization issues with ES5 spec wording [0].
After looking into this further, I'd like to recommend that we remove all the
text from 15.9.1.8 except the first sentence.
** Issue **
The current spec text 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.
Luke
[0] http://www.w3.org/International/wiki/JavaScriptInternationalization
[1] http://www.w3.org/TR/FileAPI/#dfn-lastModifiedDate
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
