search

mattjohnsonpint / TimeZoneNames

Provides a complete source of localized time zone names and abbreviations.
MIT License
196 stars 32 forks source link

Same names returned for different time zones #27

Closed es-alt closed 7 years ago

es-alt commented 7 years ago

"Eastern Standard Time" is returned for both "Eastern Standard Time" and "Eastern Standard Time (Mexico)".

"Mountain Standard Time" is returned for "US Mountain Standard Time" (Arizona) and "Mountain Standard Time".

These time zones are different (DST rules).

mattjohnsonpint commented 7 years ago

Names are not identifiers. Yes, there are many more examples of this, such as Central European Time. Humans don't always make the same distinctions that computers need.

es-alt commented 7 years ago

How do you expect humans to use the library if they can't tell one time zone from another? What am I supposed to do if I want an event to happen at a certain time in Arizona? Look at the list of available time zones, select one of the "Mountain Standard Time" and click "Feeling lucky"? You do realize that the event would happen at different times depending on which zone is selected?

mattjohnsonpint commented 7 years ago

Thanks for your feedback.

First, understand that I'm not creating these names. They're all derived from data in the CLDR. You can read about how CLDR time zone names work in the UTS-35 LDML spec.

Second, understand that the names are chosen primarily for display purposes. As in when I call new Date().toString() from JavaScript and get "Mon Jul 10 2017 13:28:04 GMT-0700 (Pacific Daylight Time)". The value in parenthesis is the daylight-long form for both America/Los_Angeles and America/Vancouver. Regardless of whether the implementer chose the daylight, standard, or generic form, there's no way to know which of those two IANA time zone IDs were the source. It's a one-way function.

Lastly, if you do want to use these names for time zone selection purposes, then there's a lot more you'll have to take into consideration, such as which set of names are appropriate to show for your given scenario. If you're dealing with historical dates, you'll have a larger number of zones than if you're dealing with relatively modern dates. I show an example demonstration of how you can deal with that in this demo. You'll note that where there is ambiguity, I have concatenated the city name. For example, to cover the United States in English for dates from today forward, the list is:

Hawaii is an interesting example point also. One would think you could just say "Hawaii Time" and "Aleutian Time" as separate values, but the legal name defined by the US Congress is "Hawaii-Aleutian Time", and so that is how it appears in CLDR.

es-alt commented 7 years ago

Thank you for a detailed answer. I was going to build a time zone dropdown with a predifined set of timezones. Didn't want to localize them myself and that's where the duplicate appeared.

It will be easier to choose only the ones I need and to localize them myself.