Grody to the Max[Date]!

by Michael S. Kaplan, published on 2008/12/16 10:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/12/16/9225748.aspx

Ben's question was a reasonable one:

Hello,

I am currently running into an issue on an Arabic localized box in which an ArgumentOutOfRangeException is being thrown when DateTime.ToString() is called on a DateTime object with the value set to MaxValue.  I understand that the valid range for DateTime values varies from culture to culture and I suspect that the MaxValue being set is not in the valid range for the Arabic locale’s calendar.  Given the variety of different calendars that need to be supported, are there are any guidelines for choosing default Max/Min DateTime values that will be valid for all cultures?

Thanks,
Ben

If you are a regular reader then this may seem like a kind of familiar problem (ref: Long term planning is not always done).

But in the meantime, Melitta stepped up with a very good and practical answer to the question:

Hi Ben,

If you look at the documentation for DateTime.MaxValue (http://msdn.microsoft.com/en-us/library/system.datetime.maxvalue.aspx), the Remarks section mentions a similar problem. 

Remarks:
The value of this constant is equivalent to 23:59:59.9999999, December 31, 9999, exactly one 100-nanosecond tick before 00:00:00, January 1, 10000.

Some calendars, such as the UmAlQuraCalendar, support an upper date range that is earlier than MaxValue. In these cases, trying to access MaxValue in variable assignments or formatting and parsing operations can throw an ArgumentOutOfRangeException. Rather than retrieving the value of DateTime..::.MaxValue, you can retrieve the value of the specified culture's latest valid date value from the System.Globalization.CultureInfo.DateTimeFormat.Calendar.MaxSupportedDateTime property.

So if you wanted to get, for example, the CurrentCulture’s Calendar’s MaxSupprotedDateTime you could have:

System.Globalization.CultureInfo.CurrentCulture.Calendar.MaxSupportedDateTime;  System.Globalization.CultureInfo.CurrentCulture.Calendar.MinSupportedDateTime;

Or you could replace System.Globalization.CultureInfo.CurrentCulture with any culture of your choice.

Here are links to the documentation on those properties:

http://msdn.microsoft.com/en-us/library/system.globalization.calendar.maxsupporteddatetime.aspx
http://msdn.microsoft.com/en-us/library/system.globalization.calendar.minsupporteddatetime.aspx

This doesn’t help if you need to have a known, hard-coded default.  But since you were using DateTime.MaxValue already, it seems like you’d be able to handle getting the data at runtime.  I hope this helps.

Thanks,
Melitta

Now this is correct -- and helpful.

It would even nicely work around the issues I mention in Theory vs. practice in software development if these dates took those issues into account (unfortunately they do not, in most cases). This meansd it will help work around the bug being reported, but not the design flaw that is the cause.

And also with an additional caveat -- note that it still won't help in the case of the Japanese Emperor calendar, which is based on the rule (and potentially the life) of the Emperor and is therefore not a known value until it happens (for more on that see Long live the Emperor).

But there really is nothing to help with that particular case. At least not that I would want to know about. :-)

So in the end it is reasonable to question the original requirement, since there will be cases where it is impossible to fulfill.....

This post brought to you by 平 (U+5e73, a.k.a. CJK IDEOGRAPH meaning 'flat, level, even; peaceful')

Joshua on 15 Jun 2011 8:52 AM:

Michael S. Kaplan on 15 Jun 2011 11:19 PM:

referenced by

go to newer or older post, or back to index or month or day