Discuss
  • Behaviour of DaylightSavingsTA in ES5.1 spec

Behaviour of DaylightSavingsTA in ES5.1 spec

# Luke Hoban (12 years ago)

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] www.w3.org/International/wiki/JavaScriptInternationalization [1] www.w3.org/TR/FileAPI/#dfn

# Norbert Lindenberg (12 years ago)

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] globalization:specification_drafts

# Andrew Paprocki (12 years ago)

On Fri, Mar 2, 2012 at 7:29 PM, Norbert Lindenberg <ecmascript at norbertlindenberg.com> wrote:

"NOTE It is recommended that implementations use the time zone information of the IANA Time Zone Database."

I don't suppose there is any desire to embed the Olson / now IANA information, ala JRE, into engines rather than relying on the OS?

In my Spidermonkey embedding case, I removed all engine interaction with the OS as far as this is concerned (prmjtime) and have a standalone, portable IANA tzdata implementation that sits alongside the engine. It is the only way I could guarantee rock solid JS Date DST information across 4 different OSes (and different patch levels of those OSes) in a situation where I control the app, but not the OS.

The browser world is a different story, but I could see the usefulness in having the default be use of internal engine IANA data (automatic browser updates take care of you) with an option to fall back on OS provided facilities if the browser has automatic updates disabled.