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.

Test Drive Demo

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 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.

Test Drive Demo In Action

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.

How to change Time Zone settings

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 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 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, 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:





  IE9 Chrome Firefox Opera Safari Node Node Chrome Firefox Safari
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.





  IE9 Chrome Firefox Opera Safari Node Node Chrome Firefox Safari
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).

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

Comments (17)

  1. Anonymous says:

    The Space Shuttle test fails for me although I am running IE10 on Windows 8, timezone is UTC+1 Berlin with DST enabled. It's computing Sun Mar 25 00:00:00 UTC+0100 1979. All other tests pass.

  2. Anonymous says:

    Any idea if future revisions of ECMAScript or anything else will provide us a portable, reliable way to get a human-readable timezone name? Came up at work: an app displays different times in different zones, and when it's the client's TZ we wanted to use a string like 'PDT' so it's unambiguous. Currently regexp'ing (new Date()).toString() to get at the timezone, but that's no fun for anyone.

  3. Anonymous says:

    You can get a string like GMT+5 or GMT+8.5 using getTimezoneOffset() of course, and that's what my app does if its regexp match fails. Just hoping for something more human-readable and involving fewer hacks in my code.

  4. Anonymous says:

    Space Shuttle test fails on my W8 Pro system with IE10 (and FF). Finnish time and date settings.

  5. Anonymous says:

    IE 10 running on Windows 7, timezone UTC Dublin/Edinburgh/London.

    The Space Shuttle test fails with "Sun Mar 25 00:00:00 UTC 1979" (wouldn't it be better to show me the time in a localised format?) and says my browser failed to convert to the correct time.  It suggests installing latest timezone updates.  I can't work out how to check if these are already installed, but they should be, as I have automatic updates enabled and the DST rules for the UK haven't changed since 2002.

    Incidentally I can't find where it tells me what the time ought to have been so that I might see how far out it was.

  6. Anonymous says:

    @Randall, there might be an issue with that, as if Microsoft continued to tie IE's date/time understanding into that of the underlying OS, they would need to make changes to Windows as well.

    If IE were to expose the OS timezone name then you could work out your own abbreviation (as far as I know, Windows stores timezone names but not abbreviations).  However, it is worth noting that in some cases the timezone names used by Windows don't correspond to those used by ordinary people.  For instance, according to .NET 4.5 running on Windows 7, my local timezone is called "GMT Standard Time" and (when DST is active) "GMT Daylight Time".  This doesn't correspond to how we use these terms in the UK.  In the UK it is understood that "GMT" always means UTC+0 and is thus inherently non-DST, and the term "GMT Daylight Time" would be considered a contradiction in terms.  We use the terms "GMT" (for UTC+0) and "BST" (for UTC+1) (British Summer Time).  But if Windows/IE were to use these terms, it would have to take account of the current culture/region/language as well – since the Irish call it Irish Summer Time.  Other terms for the same thing are WET (West European Time) and WEST (West European Summer Time) – but I have never known anyone in the UK to use them, so they might not be widely understood here (and thus not be considered human-readable).

    Still, your suggestion sounds like a useful feature, but it would need some thought.

  7. Anonymous says:

    This is all fine and well but ECMA script still has no binary safe math library in any browser.  For any site dealing with currency, that would be huge.

  8. Anonymous says:



    All the WebGL detractors on IE blog and MS employees including IE Team members that FUD about WebGL, TIME TO EAT CROW.

  9. Real McCoy says:

    @RP78, I don't see any of those test cases failing on my Windows 7 or Windows 8 systems. As far as I remember, last year (perhaps in Dec) there was an update rolled out through Windows Update for Windows 7, pertaining to time zone fixes. I don't know if it has anything to do with your problem, but you can always give it a try.

  10. Anonymous says:

    @WebGL, you have no idea what you are talking about.

    Microsoft had concerns about hardware security, as in WebGL has direct access to hardware abstraction layer (HAL), which are being addressed in latest WebGL standard specifications.

    The only FUD spreader I am seeing here is you.

  11. Anonymous says:

    RP78, that's fascinating. To answer my own question, the ECMAscript internationalization effort seems to envision standard datetime formatting tools that can also output and understand time zone names:


    Microsoft seems on board with the idea as discussed in some blog posts:




    I'd love it if IE's (new Date()).toString() looked more like Gecko's/WebKit's but MS has seemed reluctant to harmonize with Gecko/WebKit where there was no explicit standard, so I'm not holding my breath.

    (Unrelated, wow, if Microsoft implements WebGL it will be uhMAYzing.)

  12. Anonymous says:

    I apologize for crapping the important thread, but it's official, IE11 will have WebGL support.

    Microsoft: "Just when you think you got OpenGL done with, the sneaky ba-etds come up with WebGL"

    We'll soon hear that Microsoft will have a direction shift with DirectX, same as with Silverlight 😉

  13. Anonymous says:


    Open standards keep on winning over proprietary MS DirectX.

    Keep eating crow, MS.

  14. Anonymous says:

    What a DirectX slave.

  15. Anonymous says:

    @henry, There was bug in the demo due to which the Space Shuttle test was failing in some of the time zones closer to UTC. We fixed the problem last week and updated the demo as well.