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.
A remote team was hitting a bug we couldn't reproduce for several days, and I finally found it.
At one point, I'm getting ALAsset's date and converting it to DateTime.
And guess what, ALAsset's date can actually be outside of DateTime bounds.
And this will crash DateTime constructor, as in:
throw_exception + 68
mscorlib_System_DateTime__ctor_long_System_DateTimeKind + 92
monotouch_MonoTouch_Foundation_NSDate_op_Implicit_MonoTouch_Foundation_NSDate + 92
<Redacted>_AssetLibraryTab_CreateGrabboxItem_MonoTouch_AssetsLibrary_ALAsset_0 + 236
var date = (DateTime) asset.Date;
I wasn't able to find out the exact NSDate value that crashed the app but passing in NSDate.DistantFuture was enough (its SecondsSinceReferenceDate is equal to -63114076800).
I wasn't able to reproduce with NSDate.DistantFuture, but with DistantPast it does throw an exception:
var dt = (DateTime)NSDate.DistantPast;
The problem is really what to do when this happens - one solution is to cap the NSDates to DateTime.Min/Max, but that means that nsDate != (NSDate)(DateTime)nsDate, which seems strange too.
I think you're right, I have mistaken them and I meant DistantPast.
The bigger problem for me is that this exception is not at all obvious and you don't really think it's possible when casting from NSDate to DateTime. I, for one, would never have thought it's dangerous to convert asset's date to DateTime, and I'm sure anyone who needs to work with asset dates did it the same way I did—by casting—and if their users are lucky they won't get an exception. What about bindings that return DateTime instead of NSDate without realizing it's dangerous? That's what I was thinking.
Fixed to cap NSDates to DateTime.Min|Max.
The next release with this fix will be 6.0.9
mt master: 73df548e3e6cf658e00a77c818beab639124a5f1
mt ios6: 431c00b8a118004df355232393148be711d34cc6