Spring Forward: Advancing Historical Date and Time Calculations on the Web

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

When interacting with historical dates, like interpreting historical stock prices or birthdays or historical events, Web developers often have to perform validation on the server. Developers have to rely on server because Daylight Saving Time adjustments done to the dates by JavaScript engines today are not as accurate as platforms commonly run on the server like .NET, PHP / Perl, and Java. In addition to historical JavaScript dates being inaccurate, they are often not interoperable among browser platforms. Hence, developers are not able to take reliable dependency on the DST adjusted dates generated in JavaScript.

IE10 is the first browser with more accurate DST adjusted dates aligned with the changes made to section 15.9.1.8 of the ECMAScript 6 draft specification. We expanded the capabilities of the Web platform based on the scenarios where Web developers have to interact with the server for accomplishing their needs. We looked at how JavaScript engines interpret historical dates and adjust for DST. We noticed a shortcoming in the ECMAScript standards specification that prevents existing JavaScript implementations from being more accurate in adjusting for daylight savings time. We worked with the ECMAScript standards committee and proposed a specification change to drive more clarity into the next version of the ECMAScript specification.

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

Let us take a closer look at to see how the current ECMAScript specification impacts the accuracy of adjusting dates for DST in JavaScript:

Section 15.9.1.8 of ECMAScript 5.1, specifies that JavaScript implementations like Internet Explorer’s Chakra engine should typically follow while dealing with historic dates:

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.

In simplified words, this means that to deal with a historical date, a JavaScript implementation should either apply the current daylight saving time algorithm to a historic date, or determine the day for Jan 1st of a year, calculate if it was a leap year, find the current daylight saving time rules for a year with the same attributes (start day and leap year), and apply that particular daylight savings time to the historical date.  As an example for the latter, the year 1972 was a leap year that started on a Saturday.  And, the next leap year that started on a Saturday was 2000.  According to the language specification, JavaScript implementations could either use the current, or use the daylight saving rules for year 2000 while manipulating any dates for the year 1972.

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 15.9.1.8 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 15.9.1.8, 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).

Looking Ahead

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.

As the Web platform continues to grow in importance, rich application logic is now often written entirely in JavaScript, including that used by calendaring applications, spreadsheets, project management software, etc. To allow developers to maintain compatibility, this change is only enabled in IE10’s standards mode. In case you calculate historic dates in your Web applications and have custom logic to work around the inaccuracies of the browsers, you might want to ensure that the custom logic still works properly as you upgrade your Web applications to work on IE10.

-- Suresh Jayabalan, Program Manager, JavaScript Team