search

mattjohnsonpint / TimeZoneNames

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

PG (Papua New Guinea) shows Invalid Time Zone #4

Closed HobieHodge closed 9 years ago

HobieHodge commented 9 years ago

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!

mattjohnsonpint commented 9 years ago

Thanks! I'll investigate.

mattjohnsonpint commented 9 years ago

Traced it back to the CLDR. It was fixed in the latest 27.0.1 release. diff here

mattjohnsonpint commented 9 years ago

Fixed in TimeZoneNames release 1.2.1 and pushed to NuGet.

Thanks!

HobieHodge commented 9 years ago

Looks good, that was quick!

mattjohnsonpint commented 9 years ago

Fortunately, it was already corrected in the CLDR. So it just required running the existing data builder.

HobieHodge commented 9 years ago

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.

HobieHodge commented 9 years ago

TimeZoneNames.TimeZoneNames.GetAbbreviationsForTimeZone("Asia/Karachi", "en-US"); for example doesn't give me any abbreviations to work with. Along with a bunch of others.

mattjohnsonpint commented 9 years ago

Yeah, there would be issues with that kind of operation. If you like, we can chat about it on gitter

HobieHodge commented 9 years ago

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.

mattjohnsonpint commented 9 years ago

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.