New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PCL DateTimeZoneProviders.Tzdb.GetSystemDefault throws DateTimeZoneNotFoundException on non-English locale #221

Closed
GoogleCodeExporter opened this Issue Mar 15, 2015 · 4 comments

Comments

Projects
None yet
2 participants
@GoogleCodeExporter

GoogleCodeExporter commented Mar 15, 2015

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.9
5).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.

Original issue reported on code.google.com by wiyono.a...@gmail.com on 21 May 2013 at 12:56

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 15, 2015

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.)

Original comment by jonathan.skeet on 22 May 2013 at 3:33

  • Changed state: Accepted
  • Added labels: Priority-Critical
  • Removed labels: Priority-Medium
@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 15, 2015

Original comment by malcolm.rowe on 30 May 2013 at 7:36

  • Added labels: PCL
@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 15, 2015

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.

Original comment by jonathan.skeet on 22 Jul 2013 at 3:43

  • Changed state: Fixed
@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 15, 2015

Original comment by malcolm.rowe on 26 Jul 2013 at 10:03

  • Added labels: Milestone-1.1.1

@malcolmr malcolmr added the bug label Mar 15, 2015

@malcolmr malcolmr modified the milestone: 1.1.1 Mar 15, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment