March 25th, 2013
Spring Forward: Advancing Historical Date and Time Calculations on the Web
Web developers want to create world-ready applications to reach a global audience. Internet Explorer 10 brings the historical Daylight Saving Time, already available on the underlying OS, to the Web developer. This enables apps and sites to interact with historic dates and times across various time zones more accurately.
Earlier this year we explored the emerging ECMAScript Internationalization APIs that will enable things like currency representation and locale sensitive string comparison from within the Web standards platform, scenarios that previously required native interoperability or use of a plug-in. Along the same theme of making the Web platform world-ready, we published a demo exploring how browsers interact with historical date and time zone information.
Challenges with historical date and time calculations
Exploring the Test Drive Demo
To illustrate this problem and see how your favorite browser deals with historical dates, you can play with the Historic Dates Test Drive demo by clicking on any icon of an event in aerospace history at the bottom of the demo. When you do so, the browser reads the historic date when the event occurred, and shows the date and time by applying the daylight saving rule that the browser defaulted to for when the event occurred. The demo then verifies if the historic date and daylight saving is correct or not.
In the above case, when viewing the historic date for when the IMAGE spacecraft was launched, IE10 running on a Windows 8 machine in Pacific Standard Time zone is now accurately able to determine the correct date and daylight saving time for the historic event.
Note: Daylight savings time is not applicable to all time zones, and there do exist time zones where the daylight savings rules have not changed ever. In case your system is currently in such a time zone, we’d recommend you to change your system’s time zone to one where the daylight savings rules exist and have changed over a period of time (like Pacific Standard Time) and re-run the demo. While IE10 does immediately picks up the system time zone change, in case you are using any other browser, you might need to restart the browser for the updated time zone to take effect.
Improved handling of historic dates and times in IE10
The implementation of ECMAScript should not try to determine whether the exact time was subject to daylight saving time, but just whether daylight saving time would have been in effect if the current daylight saving time algorithm had been used at the time. This avoids complications such as taking into account the years that the locale observed daylight saving time year round.
If the host environment provides functionality for determining daylight saving time, the implementation of ECMAScript is free to map the year in question to an equivalent year (same leap-year-ness and same starting week day for the year) for which the host environment provides daylight saving time information. The only restriction is that all equivalent years should produce the same result.
There are two key problems when either of the above rules is used to apply daylight saving time rules to historic dates. First, the daylight saving rules for a particular time zone are not constant and change over time. This could lead to wrong rules being applied to a historic date. Second, for the time zones where daylight saving rules have changed over a period of time, Web applications are no longer able to maintain parity for those historical dates as calculated by the OS platform that they are running on, often forcing developers to hack around such interoperability problems between Web applications and the platform that they run on.
The ECMAScript 5.1 specification text in 220.127.116.11 as we saw above allows implementations to be as wrong as they would 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. Instead of constraining time zone offset behavior as in section 18.104.22.168, the specification should leave DaylightSavingsTA implementation dependent.
Our testing showed that, none of the existing browser implementations (latest versions) fully adheres to either the behavior specified in the standard across platforms or accurate in DST adjustments when dealing with dates. Here are some examples that show the difference in the US Pacific time zone:
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.
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).
Starting with Internet Explorer 10, the Chakra engine now uses the daylight saving time information available from the Windows platform that the browser runs on for conversions between local time and UTC.
After we reported the spec issue and worked with the ECMAScript standards committee to drive more clarity into the next version of the ECMAScript specification to enable the Web platform to be interoperable and more accurate, the latest draft of the ECMAScript 6 specification now details how enhanced and accurate support for daylight saving time rules should be applied to dates to produce more accurate information. IE10 the first browser that conforms to the updated specification and we hope that other browsers will also enhance their support to address the issues in their next releases, allowing Web developers to create rich world ready applications.