Thanks, Luke, for bringing this up again and doing all the research! In the ECMAScript Internationalization API specification draft [1], which we expect to be implemented on top of libraries with good time zone support, we tried to address this issue. The description of the abstract operation ToLocalTime in section 13.3.2 says:
"Apply calendrical calculations on date for the given calendar and time zone to produce weekday, era, year, month, day, hour, minute, second, and inDST values. The calculations should use best available information about the specified calendar and time zone. If the calendar is "gregory", then the calculations must match the algorithms specified in ES5, 15.9.1, except that calculations are not bound by the restrictions on the use of best available information on time zones for local time zone adjustment and daylight saving time adjustment imposed by ES5, 15.9.1.7 and 15.9.1.8." This is followed by a note: "NOTE It is recommended that implementations use the time zone information of the IANA Time Zone Database." The divergence between language specification and internationalization API specification is very unfortunate though, and it would be great if the language specification could also adopt the "use best available information about the specified ... time zone" position. Norbert [1] http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts On Mar 2, 2012, at 15:54 , Luke Hoban wrote: > 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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
