Bug 22955 - Basic DateTime calculations are throwing execptions since last update
Summary: Basic DateTime calculations are throwing execptions since last update
Alias: None
Product: Android
Classification: Xamarin
Component: Mono runtime / AOT Compiler ()
Version: 4.16.0
Hardware: PC All
: Normal normal
Target Milestone: 4.18.1
Assignee: Marek Habersack
: 22700 ()
Depends on:
Reported: 2014-09-12 15:56 UTC by frank
Modified: 2014-11-04 01:05 UTC (History)
21 users (show)

Is this bug a regression?: ---
Last known good build:

Sample Project (13.20 KB, application/zip)
2014-10-07 06:28 UTC, Parmendra Kumar

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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.

Related Links:

Description frank 2014-09-12 15:56:05 UTC
Our golive is postponed because our Azure Mobile Service sync is not working anymore since last Xamarin update.
(it was working for months before).
Basically there are some DateTime conversions that are causing the problem.
Somebody else was kind enough to make a simple failing test:

The following sample:

    DateTime baseTime = new DateTime(2014, 9, 11, 0, 0, 0, 0);
    DateTime epochTime = new DateTime(1970, 1, 1, 0, 0, 0, 0);
    TimeSpan span = baseTime.ToLocalTime() - epochTime.ToLocalTime();

yields an exception:

    ApplicationController.onUnhandledApplicationError(): terminating on error:
    System.ArgumentOutOfRangeException: Argument is out of range.
             at System.DateTime.op_Subtraction (DateTime d, TimeSpan t) [0x00000] in <filename unknown>:0 
             at Android.Runtime.AndroidCurrentSystemTimeZone.IsAmbiguousTime (DateTime time) [0x00000] in <filename unknown>:0 
             at Android.Runtime.AndroidCurrentSystemTimeZone.GetUtcOffset (DateTime time) [0x00000] in <filename unknown>:0 
             at System.TimeZone.ToLocalTime (DateTime time) [0x00000] in <filename unknown>:0 
             at System.DateTime.ToLocalTime () [0x00000] in <filename unknown>:0 

Android 4.5 L Preview running on Nexus 5 Xamarin Android 4.17.0 Xamarin Studio 5.4 (build 216)

This is the issue that we have in our sync code (basically the same as above):

System.ArgumentOutOfRangeException: Argument is out of range. at System.DateTime.op_Subtraction (DateTime d, TimeSpan t) [0x00000] in :0 at Android.Runtime.AndroidCurrentSystemTimeZone.IsAmbiguousTime (DateTime time) [0x0001d] in /Users/builder/data/lanes/1131/62e09eb0/source/monodroid/src/Mono.Android/src/Runtime/AndroidCurrentSystemTimeZone.cs:113 at Android.Runtime.AndroidCurrentSystemTimeZone.GetUtcOffset (DateTime time) [0x00049] in /Users/builder/data/lanes/1131/62e09eb0/source/monodroid/src/Mono.Android/src/Runtime/AndroidCurrentSystemTimeZone.cs:100 at System.TimeZone.ToLocalTime (DateTime time) [0x00000] in :0 at System.DateTime.ToLocalTime () [0x00000] in :0 at Microsoft.WindowsAzure.MobileServices.MobileServiceIsoDateTimeConverter.ReadJson (Newtonsoft.Json.JsonReader reader, System.Type objectType, System.Object existingValue, Newtonsoft.Json.JsonSerializer serializer) [0x00000] in :0 at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.DeserializeConvertable (Newtonsoft.Json.JsonConverter converter, Newtonsoft.Json.JsonReader reader, System.Type objectType, System.Object existingValue) [0x00000] in :0 at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.Deserialize (Newtonsoft.Json.JsonReader reader, System.Type objectType, Boolean checkAdditionalContent) [0x00000] in :0 --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x00000] in :0 at System.Runtime.CompilerServices.TaskAwaiter1[System.Collections.Generic.List1[Dvit.Apps.OpenBiz.Pcl.Models.SysType]].GetResult () [0x00000] in :0 at Dvit.Apps.OpenBiz.Pcl.Services.AzureService+d__35`1[Dvit.Apps.OpenBiz.Pcl.Models.SysType].MoveNext () [0x0006a] in c:\Code\Dvit\Dvit.Apps.Bizzumi.Android\Main\Source\Dvit.Apps.OpenBiz.Pcl\Services\AzureService.cs:390
Comment 1 Arpit Jha 2014-09-16 02:23:44 UTC
I have checked this issue and unable to reproduce it.

I tried following steps to reproduce it
1.Create a Xamarin form application.
2.Add a Class(MyPage.cs) and written above code in it.
3.Call a Mypage.cs in App.cs
4. Run the application.

  DateTime baseTime = new DateTime(2014, 9, 11, 0, 0, 0, 0);
          DateTime epochTime = new DateTime(1970, 1, 1, 0, 0, 0, 0);
          TimeSpan span = baseTime.ToLocalTime() - epochTime.ToLocalTime();
          var lbl = new Label {Text="Diffrence b/w basetime & epochtime "  +span.ToString(),TextColor=Color.Black };

I observed that getting difference of time as expected.

Let me know if I missed anything to reproduce it.

Screencast regarding Same:
Environment Info:
VS professional 2013 Update3
Comment 2 Christophe 2014-09-18 05:03:34 UTC
I created a simple android project containing one activity with the following code in OnCreate():

protected override void OnCreate (Bundle bundle)
			base.OnCreate (bundle);

			SetContentView (Resource.Layout.Main);

			string tz = TimeZone.CurrentTimeZone.GetUtcOffset(Convert.ToDateTime(@"1969-12-31

I observed the same as frank, a System.ArgumentOutOfRangeEception.

Full exception:

[MonoDroid] System.ArgumentOutOfRangeException: Argument is out of range.
[MonoDroid] at System.DateTime.op_Subtraction (System.DateTime,System.TimeSpan) <IL 0x00050, 0x002bc>
[MonoDroid] at Android.Runtime.AndroidCurrentSystemTimeZone.IsAmbiguousTime (System.DateTime) [0x0001d] in /Users/builder/data/lanes/1131/2a7b6821/source/monodroid/src/Mono.Android/src/Runtime/AndroidCurrentSystemTimeZone.cs:113
[MonoDroid] at Android.Runtime.AndroidCurrentSystemTimeZone.GetUtcOffset (System.DateTime) [0x00049] in /Users/builder/data/lanes/1131/2a7b6821/source/monodroid/src/Mono.Android/src/Runtime/AndroidCurrentSystemTimeZone.cs:100
[MonoDroid] at MonoBug.MainActivity.OnCreate (Android.OS.Bundle) [0x00033] in c:\Code\Dvit\Dvit.Apps.Bizzumi.Android\SyncTest\SyncTest\MonoBug\MainActivity.cs:28
[MonoDroid] at Android.App.Activity.n_OnCreate_Landroid_os_Bundle_ (intptr,intptr,intptr) [0x00011] in /Users/builder/data/lanes/1131/2a7b6821/source/monodroid/src/Mono.Android/platforms/android-15/src/generated/Android.App.Activity.cs:1944
[MonoDroid] at (wrapper dynamic-method) object.0deb119e-121b-421d-9c12-4ae4aa748991 (intptr,intptr,intptr) <IL 0x00017, 0x00043>

Here is my screencast of the project: http://screencast.com/t/4rfc38oRRNmQ
Comment 3 Arpit Jha 2014-09-18 06:02:48 UTC

I checked this issue with same XS build as looking in screencast.

Could you please provide us device information on which Exception occurs.

Screencast regarding same:
Environment Info
Device : Samsung galaxy s4
=== Xamarin Studio ===

Version 5.3 (build 441)
Installation UUID: f75f53ae-7c21-493c-8339-c2031a7f0448
	Microsoft .NET 4.0.30319.34014
	GTK+ 2.24.22 (MS-Windows theme)
	GTK# 2.12.25

=== Xamarin.Android ===

Version: 4.16.0 (Trial Edition)
Android SDK: D:\android-sdk
	Supported Android versions:
		1.6    (API level 4)
		2.1    (API level 7)
		2.2    (API level 8)
		2.3    (API level 10)
		3.0    (API level 11)
		3.1    (API level 12)
		4.0    (API level 14)
		4.0.3  (API level 15)
		4.1    (API level 16)
		4.2    (API level 17)
		4.3    (API level 18)
		4.4    (API level 19)
		4.4.87 (API level 20)
Java SDK: C:\Program Files (x86)\Java\jdk1.7.0_60
java version "1.7.0_60-ea"
Java(TM) SE Runtime Environment (build 1.7.0_60-ea-b15)
Java HotSpot(TM) Client VM (build 24.60-b09, mixed mode, sharing)

=== Build Information ===

Release ID: 503000441
Git revision: befb6aa1176d37a5f678f4274f340a0159091b7a
Build date: 2014-09-08 20:54:12-04
Xamarin addins: 6dc7c388e31fdfc8014689839d37de0d4622435c

=== Operating System ===

Windows 6.2.9200.0 (64-bit)
Comment 4 Christophe 2014-09-18 06:05:54 UTC
Ofcourse, this was run on a Samsung Galaxy S4Mini GT-l9195 running Android version 4.2.2.
Comment 5 Christophe 2014-09-22 09:28:11 UTC
Any updates? The sample i posted does work for me if i run it on an emulator, but impossible to make it work on a real device.
Comment 6 frank 2014-09-22 09:37:06 UTC
We have the same experience: exceptions on LG G3, but not on an emulator. 

Windows Azure Mobile Services are using DateTimeOffset fields in their backend for fields such as (__createdAt, __updatedAt, ...), on physical Android devices this is causing DateTime calculations which are throwing Exceptions all over the place (since the last Xamarin update).

Hope to have a solution soon!
Comment 7 Brendan Zagaeski (Xamarin Team, assistant) 2014-09-22 19:57:06 UTC
The key to reproducing this issue seems to be to set the device to a time zone that is _ahead_ of GMT.

For example, I was able to reproduce the problem on all the devices I tested [1] if I set the timezone to "Brussels, GMT+2:00" via "Settings -> Date & time -> Select time zone" (using the sample code from comment 2).

Curiously, setting the time zone to "West African Time, GMT+1:00" does not cause the problem, but setting the time zone to "British Summer Time, GMT+1:00" _does_ cause the problem.

[1] Mostly tested locally on an Android 4.1.2 device, but also tested via Test Cloud on several Android 4.4 devices, an Android 4.2 device, and a few Android 4.1.2 devices.

Regression status: regression

Good: Xamarin.Android 4.14.0-5 (or Xamarin 3.3.47)
Bad: Xamarin.Android 4.16.0-14 (or Xamarin 3.5.58 or Xamarin 3.6.245)

The results are the same with Xamarin Studio on Mac or Visual Studio on Windows.
Comment 8 Brendan Zagaeski (Xamarin Team, assistant) 2014-09-22 20:02:45 UTC
*** Bug 22700 has been marked as a duplicate of this bug. ***
Comment 9 Brendan Zagaeski (Xamarin Team, assistant) 2014-09-22 20:06:08 UTC
Additional interesting idea from Jonathan's description on the duplicate bug:

> my guess is that it's related to the fix for bug 20172.  This had been working
> up until the upgrade.
Comment 10 Brendan Zagaeski (Xamarin Team, assistant) 2014-09-22 20:58:03 UTC
## The problem is specific to Android

Just one more small bit of confirmation: the sample code from comment 2 does not produce any errors on iOS or desktop .NET / Mono when the time zone is set to "Brussels, GMT+2:00". The error only happens on Android.
Comment 11 frank 2014-09-23 03:05:00 UTC
Problem is specific to Android: that is also our conclusion

Our iOS version is working without problems, but Android is currently broken due to this bug.
Comment 14 Marek Habersack 2014-09-29 06:41:00 UTC
The fix for this issue was committed to our repositories (master, f2c9d2d165f5a8c248142d150a44d2b66c395cef). At this point it is unknown whether the fix will be fast-tracked to the next Xamarin.Android update.
Comment 15 Parmendra Kumar 2014-10-04 09:12:57 UTC
I have checked this issue and Its working fine at my end, So I am going to verify it.

Build Info:-

Xamarin Studio-Version 5.5 (build 227)

Xcode 6.0.1 (6528) Build 6A317

Xamarin.Android- Version: 4.18.0-34 (Business Edition)

Xamarin.Mac- Version: (Business Edition)
Comment 16 Parmendra Kumar 2014-10-04 10:00:05 UTC
I have Also checked on Windows VS, And Its working fine on VS.

Build Info:

VS 2013
XVS 3.7.203
Comment 17 Marek Safar 2014-10-06 18:46:28 UTC
@grendel, it's still buggy.

I tracked it down on Anuj machine and it's crashing in TimeZone::ToLocalTime (DateTime time) at dlt.End.Subtract because Android version of


where CurrentTimeZone info is "Central European Summer Time" gives some nonsense (probably overflow) value of

Start = 1/1/0001
End = 31/12/9999
Delta = -10675199

Note, there are bugs for multiple DST periods timezones with proposed PR1321 which can collide with the fix.
Comment 18 Parmendra Kumar 2014-10-07 06:27:40 UTC
To verify this issue I have followed these steps:
1. Create a Android Application (File->New->Solution->Android->Android Application)
2. Set TimeZone on device "Brussels, GMT+2:00"
3. Use this code on MainActivity.cs
     protected override void OnCreate (Bundle bundle)
			base.OnCreate (bundle);

			SetContentView (Resource.Layout.Main);

			string tz = TimeZone.CurrentTimeZone.GetUtcOffset(Convert.ToDateTime(@"1969-12-31 18:59:59.999")).ToString();
4. Run the application

Actual Behavior:-

Application run successfully. on Xamarin.Android 4.18.0-34
Output Log:https://gist.github.com/anonymous/c5e3de77bf097e002a89
IDE Log:https://gist.github.com/anonymous/2cb736461e0c4a5b4830

Application throw exception on Xamarin.Android 4.18.0-32
Screencast: http://www.screencast.com/t/E0gwxQSp
Comment 19 Parmendra Kumar 2014-10-07 06:28:55 UTC
Created attachment 8335 [details]
Sample Project

Sample Project
Comment 20 Christophe 2014-10-07 06:58:50 UTC
I've noticed the update of xamarin this morning was about this bug. With allot of hope i installed it just to notice it crash on the same line as before. I have also noticed it not only crashes on mid-european summertime, but on most summertime timezones. I really hope this problem gets solved pretty soon, because it makes the azure mobileservice crash at most calls, wich makes it impossible to publish our application...
Comment 21 Marek Habersack 2014-10-07 07:50:32 UTC
I can't reproduce the crasher neither with repro from comment 17 nor comment 18 using monodroid/master (on Nexus 5 runinning Android L). Will try on other devices/emulators and report back once I have any results.
Comment 22 Marek Habersack 2014-10-07 09:14:24 UTC
@marek I managed to repro your crash
Comment 23 Marek Habersack 2014-10-08 08:51:52 UTC
The current master branch (as of 6523d3595f6b5338de02c4b83d233abde9ad0051) doesn't crash in any of the above scenarios.
Comment 24 Matt Jones 2014-10-08 10:16:23 UTC
I think it would be useful to get some idea of the code that fixed this, because otherwise we're all just waiting for master to make it through alpha, beta and into stable before we can release anything with any sort of peace of mind. Whereas if we could see what fixed it we could have a good idea whether our workarounds are safe.
Comment 25 Marek Habersack 2014-10-08 10:36:42 UTC
The actual problem was that years before epoch (<= 1970) do not have correct DST data in the Java tz database. The timezone info does report that it has DST and what is its offset, but if you iterate over the year's days and ask for each of them whether it is inside or outside the DST, it will return 'false' to all of them. The same process works correctly for years > 1970. On top of that, the default values we used for DaylightTime returned from the API were DateTime.{MinValue, MaxValue} for the {Start, End} properties and Delta was initialized to TimeSpan.MinValue. That caused subtraction exceptions to be thrown and since there was not a single day in DST, we returned DaylightTime instance with those default values. Currently the returned instance is initialized with DateTime (0) for {Start, End} and TimeSpan.Zero for Delta - the same values used when the given timezone does not use DST at all.

This fixes the crashes, but we need to figure out a way to return valid DST data for years <= 1970 which will be done in near future. Unfortunately, the timezone data situation on Android is... complex to put it gently.
Comment 26 Matt Jones 2014-10-08 10:57:52 UTC
That's a really helpful update, thanks very much, I appreciate it.
Comment 27 Marek Habersack 2014-10-08 11:11:43 UTC
@Matt you're most welcome!
Comment 28 blake.meinke 2014-10-10 09:39:12 UTC
@Marek Habersack
Any word on when the fix will be released?
Comment 29 Marek Habersack 2014-10-10 09:44:33 UTC
It is being QA-d now, hopefully soon if there are no regressions found.
Comment 30 Christophe Oosterlynck 2014-10-20 16:23:54 UTC
I'm running into similar problems as described in comment 17 by Marek Safer. Although not with years < 1970 but years > 2038:


returns the same values as for years < 1970:

Start = 1/1/0001
End = 31/12/9999
Delta = -10675199

This results in not being able to parse this date for example:



System.Diagnostics.Debugger.Mono_UnhandledException_internal () in 
System.Diagnostics.Debugger.Mono_UnhandledException (ex={System.ArgumentOutOfRangeException: Argument is out of range.
at System.DateTime.Subtract (System.TimeSpan) <IL 0x0002b, 0x0010f>
at System.TimeZone.ToLocalTime (System.DateTime) <IL 0x000ee, 0x008d7>
at System.DateTime.ToLocalTime () <IL 0x0000b, 0x00054>
at System.DateTime._DoParse (string,string,string,bool,System.DateTime&,System.DateTimeOffset&,System.Globalization.DateTimeFormatInfo,System.Globalization.DateTimeStyles,bool,bool&,bool&,bool) <IL 0x01357, 0x05427>
at System.DateTime.CoreParse (string,System.IFormatProvider,System.Globalization.DateTimeStyles,System.DateTime&,System.DateTimeOffset&,bool,System.Exception&) <IL 0x000ca, 0x0041f>
at System.DateTime.Parse (string,System.IFormatProvider,System.Globalization.DateTimeStyles) <IL 0x0001d, 0x000cf>
at System.DateTime.Parse (string,System.IFormatProvider) <IL 0x00003, 0x00033>
at System.DateTime.Parse (string) <IL 0x00002, 0x0002f>
at System.Convert.ToDateTime (string) <IL 0x0000d, 0x0007b>
at Axa.Mobile.Core.App..ctor () [0x00021] in /Users/christophe/src/axa-mobile-other/Axa.Mobile.Core/App.cs:25
at Axa.Mobile.Core.App.get_Instance () [0x00028] in /Users/christophe/src/axa-mobile-other/Axa.Mobile.Core/App.cs:123
at Axa.Mobile.Tablet.Droid.AxaActivity.OnCreate (Android.OS.Bundle) [0x00001] in /Users/christophe/src/axa-mobile-other/Axa.Mobile.Tablet.Droid/Axa.Mobile.Tablet.Droid/Activities/AxaActivity.cs:38
at Axa.Mobile.Tablet.Droid.MainActivity.OnCreate (Android.OS.Bundle) [0x00026] in /Users/christophe/src/axa-mobile-other/Axa.Mobile.Tablet.Droid/Axa.Mobile.Tablet.Droid/Activities/MainActivity.cs:95
at Android.App.Activity.n_OnCreate_Landroid_os_Bundle_ (intptr,intptr,intptr) <IL 0x00013, 0x0008b>
at (wrapper dynamic-method) object.1eb7fbf2-4898-467e-838e-a8853d1548c3 (intptr,intptr,intptr) <IL 0x00017, 0x0001f>
}) in 
object.1eb7fbf2-4898-467e-838e-a8853d1548c3 (arg0=0xffffffffb93b4788, arg1=0x1d000019, arg2=0x0) in 
System.DateTime.Subtract (value={-10675199.02:48:05.4775808}) in 
System.TimeZone.ToLocalTime (time={13/08/2044 19:07:12}) in 
System.DateTime.ToLocalTime () in 
System.DateTime._DoParse (s="2044-08-13T21:07:12.510+02:00", firstPart="yyyy/M/dT", secondPart="H:m:s.fffffffzzz", exact=false, result={13/08/2044 19:07:12}, dto={13/08/2044 21:07:12 +02:00}, dfi={System.Globalization.DateTimeFormatInfo}, style=System.Globalization.DateTimeStyles.AllowWhiteSpaces, firstPartIsDate=true, incompleteFormat=false, longYear=false, dateTimeOffset=false) in 
System.DateTime.CoreParse (s="2044-08-13T21:07:12.510+02:00", provider={nl-BE}, styles=System.Globalization.DateTimeStyles.AllowWhiteSpaces, result={13/08/2044 19:07:12}, dto={13/08/2044 21:07:12 +02:00}, setExceptionOnError=true, exception=(null)) in 
System.DateTime.Parse (s="2044-08-13T21:07:12.510+02:00", provider=(null), styles=System.Globalization.DateTimeStyles.AllowWhiteSpaces) in 
System.DateTime.Parse (s="2044-08-13T21:07:12.510+02:00", provider=(null)) in 
System.DateTime.Parse (s="2044-08-13T21:07:12.510+02:00") in 
System.Convert.ToDateTime (value="2044-08-13T21:07:12.510+02:00") in 

Wil this problem be fixed with the fix for this bug or should I report a new bug?
Comment 31 frank 2014-10-21 03:43:24 UTC
Dear Xamarin team,
Our go live is still on hold because of this bug: our app generates exceptions in our TimeZone (Brussels). When will there be a fix available is the stable version?
Thanks for your feedback, Frank
Comment 32 Marek Habersack 2014-10-21 04:38:12 UTC
It is being QA-d now, I can't answer the question when it will hit the stable release exactly, though.
Comment 33 Rik Dodsworth 2014-10-22 06:49:17 UTC
I noticed that a fix has been released. However, it doesn't fix the issue in our application. We are still getting the exception.

System.ArgumentOutOfRangeException: Argument is out of range.
  at System.DateTime.Subtract (TimeSpan value) [0x00000] in <filename unknown>:0
Comment 34 Marek Habersack 2014-10-22 06:59:10 UTC
@Rik, can you please provide the full stack trace? And, if possible, a small repro using the code that triggers the issue for you.
Comment 35 Rik Dodsworth 2014-10-22 07:18:41 UTC
Thanks for getting back so soon.
The issue was happening inside JSON.Net but I've managed to reproduce in two lines of code.

My stack strace is below. Thank you!

var dt = DateTime.MinValue;
var dt1 = dt.ToLocalTime();

For what it's worth. This works fine on iOS.

 at System.DateTime.Subtract (TimeSpan value) [0x00000] in <filename unknown>:0 
  at System.TimeZone.ToLocalTime (DateTime time) [0x00000] in <filename unknown>:0 
  at System.DateTime.ToLocalTime () [0x00000] in <filename unknown>:0 
  at Kafehaus.App.Android.Setup..ctor (Android.Content.Context context)
*** the rest is ommited as its not relevant.
Comment 36 jonathan_chapman 2014-10-22 12:11:20 UTC
@Rik, I would say from Comment 35 that his is not an issue.  If you're in North America and do DateTime.Minvalue.ToLocalTime() then you're taking MinValue and subtracting say 4 hours.  This will of course be below MinValue, which will give you the ArgumentOutOfRangeException.
Comment 37 Rik Dodsworth 2014-10-22 12:21:54 UTC
Unfortunately I don't agree. Simply because this works in the .Net framework and it works fine in iOS. It also works fine in Android when we're in GMT+0

I understand your point of view but our bug is inside the JSON.Net and without a modification to that code to work around this specific bug, this is a blocker for us releasing our application.

We use MinValue to represent an unset date because JSON.Net doesn't work with Null date values.

Comment 38 jonathan_chapman 2014-10-22 12:37:06 UTC
I would suggest you double check the JSON string to make sure the timezone indicator is present.  We had this same problem between Chrome and IE.  One would deserialize as UTC and one in local time.  We put a "Z" at the end on the client before converting to a date to make sure they were both handled the same way.  This sounds like the same problem here.
Comment 39 Rik Dodsworth 2014-10-23 05:58:02 UTC
Hi @Jonathan. Having to pre parse a JSON string before I pass it using JSON.Net isn't a suitable solution as that will add further overhead to the parsing functionality.
Also, Because these dates are Microsoft JSON dates, like Date(12344+0000) for e.g we don't have the option to manipulate the format of the date prior to it going through the JSON parser.

As I said previously, this works fine on other platforms and if it's a x-platform solution then it should behave the same across all. 

If I manipulate the data first it would take some jigging of the code so that we can still do things like if(fred == DateTime.MinValue) because if we have to adjust the time before parsing, it wont be MinValue.

Final point, even if i move the date on by a whole day and do ToLocalTime. It still fails. So MinValue + 1 day shouldnt fail, but it does.

I still feel like this is a bug and not an implementation problem.
Comment 40 Matt Jones 2014-10-23 06:05:57 UTC
You're dead right it is a bug and what's more, it's a regression too. Can't really understand why the 'glue' can't catch the exception and adjust it? MinValue is MinValue, after all. Infinity plus one is still infinity.

Don't underestimate how scary it is to find regressions like this when you're writing a financial app that relies on a lot of third party code.
Comment 41 Marek Habersack 2014-10-23 07:54:40 UTC
(In reply to comment #40)
> You're dead right it is a bug and what's more, it's a regression too. Can't
> really understand why the 'glue' can't catch the exception and adjust it?
> MinValue is MinValue, after all. Infinity plus one is still infinity.
It's not the exception that is the problem. Catching it and ignoring would hide the actual cause instead of fix the bug and in effect the bug would pop up somewhere else at some other time. The fix for this bug is going to be part of 4.18.1

> Don't underestimate how scary it is to find regressions like this when you're
> writing a financial app that relies on a lot of third party code.
Comment 42 Marek Habersack 2014-10-23 08:19:50 UTC
@Rik, @Jonathan Rik is right that it's an actual bug and that all platforms should exhibit the same behavior. 

Desktop Mono doesn't have the issue with timezones using negative UTC offsets and I'm happy to report that the upcoming 4.18.1 does not exhibit the issue either.
Comment 43 Rik Dodsworth 2014-10-23 09:04:35 UTC
@Marek Excellent! Looking forward to the update.
Comment 44 Parmendra Kumar 2014-10-28 07:33:47 UTC
I have checked this issue as comment #17 
on build XS-Version 5.5.3 (build 6), X.Android-Version: 4.18.1 (Business Edition)
and the value is

Delta {00:00:00}
End {01/01/0001 00:00:00}
Start {01/01/0001 00:00:00}

The application build successfully. 
Screencast: http://www.screencast.com/t/JeCLYHSFR4Pq
Could you Please tell me that Is it correct behavior or not ?.