Out of [implied] range

The question was something like:

I have a japnese OS and japnese .net installed on it. The DateTime format is set to gregorian calendar in japnese and when I execute the following piece of code I am getting an argumentoutofrange exception. Any idea what could be the problem

Console.Writeline(constants.Data.SqlTypes.SqlDateTime.MinValue);

However If I do it by providing cultureinfo.invariantculture to the string things appear to work fine. Is it the case that minvalue is culture independent and cant really be converted to a String in certain cultures like JPN?

As a first step, looking at my prior post Long Live the Emperor, it has the earliest supported date in the Japanese Emperor calendar as being August 9th, 1868.

As a next step, System.Data.SqlTypes.SqlDateTime.MinValue has as its earliest supported date January 1, 1753.

So clearly, the most likely explanation for the problem here is that the Gregorian calendar is not what is being used here.

Perhaps this is actually a good object lesson about being careful about default data type coercions (such as this one between SqlDateTime and System.String) -- because it can be hard to predict how that coercion might happen across multiple people and multiple versions....

So let's see if we can figure out what did happen. Obviously the .NET Framework felt comfortable with the coercion, so it must have figured it would be lossless. Let's start by looking at all of the Console.WriteLine() overloads....

Hmmmm. No DateTime overload. Ok, let's go to the DateTime.ToString overloads....

Aha! If you do not pass a CultureInfo object (which obviously the implicit call does not), then you do not get any special overrides based on the CultureInfo object that has been modified to use the Gregorian calendar. But according to the DateTime.ToString() topic, "The value of the current DateTime object is formatted using the general date and time format specifier ('G').", described in Standard DateTime Format Strings as representing "...a combination of the short date (d) and short time (t) patterns, separated by a space." Which maybe it is doing, but it does not mention what CultureInfo it will be using, or whether overrides/changes in the CultureInfo will be used.

Or maybe the person asking the question did not actually set the calendar to Gregorian properly, and everything is working as expected?

An interesting problem not documented terribly well, in any case -- and a great argument to be explicit when it comes to formats? :-)

This post brought to you by  ᠆ (U+1806, a.k.a. MONGOLIAN TODO SOFT HYPHEN)