1. Jon Nylander
  2. jsTimezoneDetect
  3. Issues

Issues

Issue #76 invalid

Backwards Incompatible Changes

Dan Deming
created an issue

I have attempted to upgrade to the latest version of jsTimezoneDetect from a version dated 1/19/12 and noticed a fair amount of backwards incompatible changes that are not documented anywhere.

Specifically, this script used to return the name of the user timezone, the offset and whether or not it is subject to DST. Now, it returns only the name.

To compound matters, I wasn't able to figure out any way to get the timezone offset from the script, even though it still seems capable of doing so. If I modify the script to expose "lookup_key" as a public method, I can get the offset via:

var offset = jstz.lookup_key(jstz.determine().name()).split(',')[0]

This gives me an offset that is close to what the script previously returned, but in the wrong format. Previously, the offset would be in the format -05:00 and now it's -300. With some more string manipulation, I can get it to where I need it to be.

This brings up several questions: 1) Why was the script changed to no longer return this data? The script seems much less useful now. 2) Am I missing something or is the only way to get this data to make a local modification to add lookup_key as a publicly exposed method? Any reason this method can't be exposed? 3) MINOR TYPO: The "determine_timezone" method was apparently replaced with "determine" but is still referenced in a comment on line 278. 4) How about restoring determine_timezone() to preserve the original behavior but also trigger a deprecation warning via:

if (console && console.warn) console.warn('determine_timezone is deprecated');

I believe this is how other projects handle changing APIs. This would enable backwards compatibility while steering people toward using the new API.

5) I'm unclear on what the original behavior of the timezone.dst flag was in the earlier version of the script. Since I need this value back, is it better to infer this value from:

jstz.lookup_key(jstz.determine().name()).split(',')[1]

OR

jstz.date_is_dst(new Date())

Out of curiosity, what, if any, is the difference between the two?

Comments (3)

  1. Jon Nylander repo owner

    1) Why was the script changed to no longer return this data? The script seems much less useful now.

    You are free to feel that way. To sum up: keeping track of changes in whether a tz supports dst or not is tricky, the rules change. I would rather spend my time returning the names of timezones so that developers can start using them for datetime normalizations (this is the scope of the script).

    2) Am I missing something or is the only way to get this data to make a local modification to add lookup_key as a publicly exposed method? Any reason this method can't be exposed?

    I will not expose it, you can if you want to. I am not interested in developing or maintaining code for returning meta data about a time zone. Only the name.

    3) MINOR TYPO: The "determine_timezone" method was apparently replaced with "determine" but is still referenced in a comment on line 278.

    Thanks.

    4) How about restoring determine_timezone() to preserve the original behavior but also trigger a deprecation warning via: if (console && console.warn) console.warn('determine_timezone is deprecated');

    If I remember correctly I did this for a long time before removing that code. Removing code is not a bad thing, and I don't have the spare time to intricately document my deprecation decisions.

    I believe this is how other projects handle changing APIs. This would enable backwards compatibility while steering people toward using the new API.

    5) I'm unclear on what the original behavior of the timezone.dst flag was in the earlier version of the script. Since I need this value back, is it better to infer this value from: jstz.lookup_key(jstz.determine().name()).split(',')[1] OR jstz.date_is_dst(new Date()) Out of curiosity, what, if any, is the difference between the two?

    The dst flag returned true if a timezone used dst generally, not if the time zone was currently in dst. This was a source of confusion for many, and also hard to maintain because several timezones stopped using DST but were still correctly detected (name found) by the script. If you want to know whether a timezone uses dst, create a date in january and in june, if the GMT offsets differ, the zone the client is in uses DST. Neither of your two examples above accomplish this on their own.

  2. Log in to comment