GetTimeZonesForCountry("CA", "en-US")

[HobieHodge]

Hi, I got the latest from Nuget this morning to see if it corrected a separate problem providing locale info for Kazakhstan. It did in fact correct that issue, but then I noticed a separate problem: The method below returns an invalid time zone error for Canada "CA". I'm sure the previous version I had used did not have this problem.

TimeZoneNames.TimeZoneNames.GetTimeZonesForCountry("CA", "en-US")

A first chance exception of type 'System.ArgumentException' occurred in TimeZoneNames.dll 'TimeZoneNames.TimeZoneNames.GetTimeZonesForCountry("CA", "en-US")' threw an exception of type 'System.ArgumentException' base: {"Invalid Time Zone\r\nParameter name: timeZoneId"} m_paramName: "timeZoneId" Message: "Invalid Time Zone\r\nParameter name: timeZoneId" ParamName: "timeZoneId"

Thanks, Hobie

[HobieHodge]

america/fort_nelson isn't in the Data.CldrAliases. So it returns a null value back from GetCldrCanonicalId(), throwing that error. Not sure the best way to handle that.

[HobieHodge]

Hi MJ, So I got a little desperate. I tracked down the missing time zone entry to this cldr file: ..\cldr\common\bcp47\timezone.xml I went in and added a row to that file near to some of the other Canada rows:

I just made up the name “cayzz” since I’m not really sure what that element is used for. I then rebuilt the data source and the portable library, removed my NuGet reference to TimeZoneNames and just referenced my quick-fix build instead.

Do you have any sway with the CLDR folks to see if Fort Nelson can be added to the official source data? I’m assuming that is where this xml file comes from.

Thanks, Hobie

[HobieHodge]

amendment... type name="cayzz" description="Fort Nelson, Canada" alias="America/Fort_Nelson"/ was the row I added. Just noticed previous comment didn't include what I pasted from my xml file. No mastery of "markdown" for commenting on my part.

[mattjohnsonpint]

It's already been added to the development ("trunk") branch of CLDR. You can see it here: http://unicode.org/repos/cldr/trunk/common/bcp47/timezone.xml

CLDR releases are biannual, in March and September. See http://cldr.unicode.org/index#TOC-General-Schedule-

That can create somewhat of a problem for libraries such as this one, where we need the most up-to-date information with each TZDB release. Ultimately, I think some of this has to be managed manually.

I'll see what I can do about refreshing the library with the relevant changes to avoid exceptions.

Thanks.

[HobieHodge]

Thanks, appreciate your work on this and on the complexity of dealing with separate standards providers to get to the desired end. Do you know offhand if Microsoft has any plan to try and tackle the issues your library addresses with any future .Net Framework enhancements?

[mattjohnsonpint]

With specific regard to localization of timezone names, I do not believe there is anything planned within .NET framework itself. However, if you're writing WinRT based applications (phone, store, universal, etc.), There is the Windows.Globalization.Calendar class, which has some localization ability. It's not a very friendly API though - IMHO.

[mattjohnsonpint]

Fixed with e846f7e6efdb1e72ef834f6b2b2b46b6213bcf19 in version 1.3.1.

Thanks!

[HobieHodge]

Awesome, Thanks Matt.