Issue 221 in noda-time: PCL DateTimeZoneProviders.Tzdb.GetSystemDefault throws DateTimeZoneNotFoundException on non-English locale

[noda...@googlecode.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 221 by wiyono.a...@gmail.com: PCL
DateTimeZoneProviders.Tzdb.GetSystemDefault throws
DateTimeZoneNotFoundException on non-English locale
http://code.google.com/p/noda-time/issues/detail?id=221

DateTimeZoneProviders.Tzdb.GetSystemDefault on PCL build throws
DateTimeZoneNotFoundException when the display language (this is as tested
on WP8) is set to non-English.

Digging into the source, I found that on PCL, the library uses
TimeZoneInfo.StandardName instead of normally TimeZoneInfo.Id for looking
up the mapping. This apparently, is a localised name
(http://msdn.microsoft.com/en-GB/library/system.timezoneinfo.standardname(v=vs.95).aspx)
so this would not work properly. Eg. "Westeuropäische Zeit" instead of "GMT
Standard Time".

From my testing, I do find that the m_id private field of TimeZoneInfo is
correctly set (at least on WP8), and in this case: "GMT Standard Time.
However there may be a security restriction to access this field
reflectively!

This is on version 1.1.0 from NuGet. And it is the PCL and as tested on WP8.

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[noda...@googlecode.com]

Updates:
Status: Accepted
Labels: -Priority-Medium Priority-Critical

Comment #1 on issue 221 by jonathan.skeet: PCL

DateTimeZoneProviders.Tzdb.GetSystemDefault throws
DateTimeZoneNotFoundException on non-English locale
http://code.google.com/p/noda-time/issues/detail?id=221

Humbuggy humbug.

It looks like this is localized in the system culture, regardless of any
other changes made in software. The only ways I can think of to fix this
are:

1. Maintain the standard names of all time zones in all cultures (bad idea)
2. Dynamically look through the TZDB time zones, checking for offset
matches. (Possibly use the existing Windows mapping data to narrow down the
possibilities to start with.)

I'm not sure I really *like* option 2, but I haven't got any better ideas
at the moment. I wonder how hard it is to tell the difference between time
zones with the same base offset... (It'll be *slow* of course, but I can
probably live with that. It could always just be a backup if we can't find
it by name.)

[noda...@googlecode.com]

Updates:
Status: Fixed

Comment #3 on issue 221 by jonathan.skeet: PCL

DateTimeZoneProviders.Tzdb.GetSystemDefault throws
DateTimeZoneNotFoundException on non-English locale
http://code.google.com/p/noda-time/issues/detail?id=221

This should now be mostly fixed by revisions a6597b07c8db (default branch)
and b5a79c33a147 (1.1 branch).

We start off by checking by name, and otherwise find all candidate zones
and check for the one which matches transitions this year best. It's a bit
hacky, but seems to usually get the exact right zone, and where it doesn't
it's almost always equivalent to the right zone.

I need to update the docs with a bit more information on this, and then
we'll build a new 1.1 release.

[noda...@googlecode.com]

Updates:
Labels: Milestone-1.1.1

Comment #4 on issue 221 by malcolm.rowe: PCL

DateTimeZoneProviders.Tzdb.GetSystemDefault throws
DateTimeZoneNotFoundException on non-English locale
http://code.google.com/p/noda-time/issues/detail?id=221

(No comment was entered for this change.)