Issue #68 invalid

Effects of ECMAScript 15.9.1.8

Matt Johnson avatarMatt Johnson created an issue

It's recently come to my attention that there is a flaw in the ECMAScript specification that almost all browsers use for their JavaScript implementation.

This is discussed here: http://stackoverflow.com/a/16951442/634824

The actual spec is in ECMAScript 5.1 section 15.9.1.8

The troubling part is as follows:

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.

It ends up that Firefox, Chrome, Safari and Node.js all take the "easy route" and apply the current time zone rules to past dates. Even if the operating system has more data about past dates, they do not pick it up! Of those tested, only IE is going the route of providing accurate data for past dates (and we all know that Windows time zones are proprietary anyway).

So I know you had said that jsTimeZoneDetect uses dates after 2010 to determine the timezone key - but for those browsers that look at only the current timezone rules, there is still going to be an issue. We might be using a 2010 or 2011 test date, but their browser has a timezone that was updated in a more current update (such as any of the 2012 or 2013 updates).

So, I think that means that jsTimeZoneDetect logic will break for users that are in time zones that change, assuming they get the updates for those changes. Is this argument sound? Or is there something I'm not thinking about that makes it more reliable?

I'm really not certain of a way to stay on top of this - unless you plan to continually release updates to jstz with new key test dates and corresponding logic. Getting these updates in an automated manner will be fairly difficult. And since not everyone will have the corresponding tzdb or winzone changes, the library would have to get bigger and bigger to support lots of variations and past versions...

Sorry if I just blew a hole in this library. It's one of my favorites, but now that the wool has been pulled off my eyes, I'm not so sure it's going to hold up over time. I am infuriated with ECMA right now. This part of their spec is so troubling on so many levels, and I'm not sure what can really be done about it.

So much of what I use in other date libraries is based on javascript Date - and I always knew that it reflected only the local time zone, but I have been working on the assumption that it honors the operating system's representation of that zone - not some convoluted shortcut mechanism that it really is.

I think I am going to have to evaluate the 5 different tzdb javascript libraries I have found and figure out which one(s) are actually viable. All js Date are suspect to me now...

Or maybe I am being to harsh. What do you think? I am so sad about this right now. Sorry for the rant.

Comments (3)

  1. Jon Nylander

    Hmm, not sure you blew a hole in it. But it may explain why I need to update it from time to time.

    I am afraid I don't have neither the knowledge or the time at hand to attach the JavaScript spec itself. I've used jstz for years in my business and so far it is remarkably stable.

  2. Matt Johnson

    That's good to hear. But if you ever get more time to dig deeper, please let me know.

    This definitely would explain any tests that pass on some browsers and fail on others.

    With regards to IE, It's only IE10 that returns valid offsets for past dates. Perhaps they are just early adopting ES6. IE9 and prior still follow ES5 like the other browsers.

  3. Log in to comment
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.