GetAbbreviationsForTimeZone returns non abbreviation names.

[gorilla227]

When I call TZNames.GetAbbreviationsForTimeZone("Asia/Seoul", "en-US");, I expected the abbreviation name like "KST". However, I got "South Korea Time"(Generic), "South Korea Standard Time"(Standard) and "South Korea Daylight Time"(Daylight).

[mattjohnsonpint]

Yeah, abbreviations are a pain unfortunately. For various reasons, I am considering dropping them altogether. How important are they to you?

[gorilla227]

I'm so sad to hear about that. I think I might need figure out another way to deal with it.
Thanks any way.

[miroslavgrozdanovski]

@mj1856 , do you have any other recommended way in mind to get the timezone abbreviations?

So far we've used your library in combination with TimeZoneInfo.IsDaylightSavingTime, which is needed to decide which abbreviation to use from those that your library provides. But after some analysis, this library provides abbreviations for only 55 out of the 140 Windows timezones. I'm searching for alternatives, but most of the answers point me back to your library :)

We can make a change and start using IANA timezones, but I don't see a difference when abbreviations are concerned.

Thanks!

[mattjohnsonpint]

Unfortunately, no. In general, the concept of a time zone abbreviation is a Western convention, and most are English. They aren't standardized, and there are lots of ambiguities and conflicts. The assumption that all time zones must have an abbreviation is one of those things that English speaking developers have imposed upon the world. It's simply not the reality.

IANA has been correcting this by replacing a lot of the "invented" abbreviations with numbers.

Unicode (CLDR/ICU) has simply never imported most abbreviations. They have just some of the common North American and European ones in English and a few in French. Not much other than that.

I recommend working them out of your system if possible, or only using them where they are widely understood and the context is limited to a single country.

For example, if you are targeting the US, you could use "CST" for Central Standard Time. But if your audience is global then that might get misinterpreted as China Standard Time or Cuba Standard Time. So better to avoid them.

[Carmageddon]

@mattjohnsonpint I don't quite understand why not add the widely accepted conventions in non-western countries?
For example Omsk Standard Time that the library returns, seems to be quite well known and shows as OMST:
https://www.timeanddate.com/time/zones/omst

I can understand wanting to avoid ambiguity, but at least for English locale, why not have all known abbreviations available?
A precise list of what is available could be helpful too..

[mattjohnsonpint]

Closing. Will track abbreviations issue in #91. Thanks.

[mattjohnsonpint]

Regarding OMST - that's not in TZDB or CLDR. So again, we need better source data.