This is discussed here: http://stackoverflow.com/a/16951442/634824
The actual spec is in ECMAScript 5.1 section 184.108.40.206
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.
Or maybe I am being to harsh. What do you think? I am so sad about this right now. Sorry for the rant.