Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
This piece of code, from ServiceStack.Text (well, I've distilled it from there)
var tz = TimeZoneInfo.Local;
var offset = tz.GetUtcOffset(DateTime.Now);
Causes a NullReferenceException (tz / TimeZoneInfo.Local is null) when the timezone of the device is NZDT (GMT+13). Which it is now, in New Zealand.
I have tested this on Android 2.3 and another version (4.x - not sure, it was a customers device) and I can reproduce it.
I also tried it on iOS6 / MonoTouch 6.0.3 (latest beta), and it works fine.
For context, it's here in SS.T:
And for more context, here's how we determine the default timezone:
What is the output of:
adb shell getprop persist.sys.timezone
If the persist.sys.timezone system property is empty, this is probably a dup of Bue #4902. If it isn't empty, this may be a dup of Bug #7966 (and a TimeZoneNotFoundException should be thrown instead of `null` being returned).
cynophobia:platform-tools nic$ ./adb shell getprop persist.sys.timezone
Thing is, Pacific/Auckland is VERY VERY valid. (I was born there)
Setting status to NEW as Nic provided the requested info.
I have currently the same issue where Json.NET crash because TimeZoneInfo.Local is null.
This was on a brand new device(LG) without a sim card and time zone settings set to automatic(from network).
Using adb the persist.sys.timezone was reported as an empty line.
On the phone the timezone is reported as GMT+00:00.
Perhaps this could be used when persist.sys.timezone is empty.
After setting the timezone manually in the settings the error no longer occurs.
Fixed in master/bd1efe1d, and should make it into the 4.8 release.
The problem? I was searching for strings wrong: https://github.com/mono/mono/commit/ac11abe1
Sorry to re-open this, but we upgraded a Nexus 7 to 4.3 and now at runtime, the value of TimeZoneInfo.Local is null again. This showed-up as an exception from Newtonsoft.Json.
> adb shell getprop persist.sys.timezone
Thought I'd add to this instead of opening a new bug with the same description.
TimeZoneInfo.Local null on Android v4.3 is Bug #13686, which if fixed in Xamarin.Android 4.8.2.
We ran into the same thing today using 4.10.2 and Android 4.1.2 on a Samsung Galaxy Note 2 that no longer has a sim card installed. Runs fine on Nexus 5 and Android 4.4.2.
@Trent: What's the output of the following command?
adb shell getprop persist.sys.timezone
@Jon: It is blank on my Galaxy Note 2 running 4.1.2. Nexus 5 running 4.4 is America/Denver
It is also null in the GenyMotion simulator for a Nexus 5. Running Xamarin.Android 4.12.1
I see it, too, with Genymotion (random OS). I think you should set timezone there manually (avoid get timezone from network). It looks to like an Android problem. Or perhaps there is another way to retrieve TimeZone or set a default one if none is set.
It would be nice if there were a solution or workaround for this. It is still there in Xamarin.Android 4.12.3
There are two different bugs on this thread:
1. TimeZoneInfo.Local is null when the persist.sys.timezone system property is NOT null; and
2. TimeZoneInfo.Local is null when persist.sys.timezone IS null.
Bug (1) is Comment #0 through Comment #3, and was fixed in Xamarin.Android 4.8. (Then a ~repeat for Android v4.3+, via Comment #7 and Bug #13686.)
Bug (2) is Comment #4 and Comment #9 through 14; these are duplicates of Bug #4902, which will be fixed in the forthcoming Xamarin.Android 4.14 release.