Closed HobieHodge closed 9 years ago
Thanks! I'll investigate.
Traced it back to the CLDR. It was fixed in the latest 27.0.1 release. diff here
Fixed in TimeZoneNames release 1.2.1 and pushed to NuGet.
Thanks!
Looks good, that was quick!
Fortunately, it was already corrected in the CLDR. So it just required running the existing data builder.
FYI, I'm trying to use it to convert the somewhat ambiguous abbreviation codes to the IANA Region/City code by providing a country code with the abbreviation. For example:
EEST, RO => Europe/Bucharest.
It is a more challenging task than I expected. It mostly works ... but not in every case.
TimeZoneNames.TimeZoneNames.GetAbbreviationsForTimeZone("Asia/Karachi", "en-US"); for example doesn't give me any abbreviations to work with. Along with a bunch of others.
Yeah, there would be issues with that kind of operation. If you like, we can chat about it on gitter
gitter is blocked at my work, as are similar on-line communication venues (data security protocols). Surprised that github isn't entirely blocked. I've not gotten deep into the CLDR source data, it just looks to be not complete enough to perform this type of backward translation for the abbreviations. It is close though, so close... I'll probably kick myself later, but I'm just going to supplement the dozen or so missing abbreviation items that my project needs as config settings and go with it.
In general, abbreviations are intended for display purposes, and don't always map backward in a clean manner. With the country code added, I think you will have fewer ambiguities, but there will probably still be a few that are unresolvable.
And yes - CLDR is missing abbreviations for many zones. However, while IANA has abbreviations for all zones, they only have English abbreviations, and in many cases they are invented to fill the knowledge gap. There's some discussion going on right now on the TZ mailing list about MSK being used for Minsk, where Minsk traditionally wouldn't use an abbreviation at all, and MSK is confused with Moscow - which becomes a political issue for Minsk.
Also, they don't always follow common sense, such as HAST/HADT being used for the Aleutian Islands traditionally, but switched recently to HST/HDT such that Hawaii's common HST applies in Adak, Alaska. :confused:
Good look with the mapping, but it may prove to be a futile exercise to capture the whole world. Focus on the areas you care about in your particular application.
TimeZoneNames.TimeZoneNames.GetTimeZonesForCountry("PG", "en-US") threw an Invalid Time Zone error. Should be coming up with Pacific/Port_Moresby? All the other countries I'm using resolved properly from what I've seen so far. Great utility by the way!