.NET is too busy being consistent with Windows to be consistent with itself....

Back in the early days of the planning for the .NET Framework, everyone was convinced that the CultureInfo class really needed to base itself off of the settings on the underlying version of Windows. People were simply convinced that it would be too confusing if they changed the date format or whatever in Windows, and the CurrentCulture did not pick up the change there.

Maybe they were right, but to be honest I have always been skeptical as to whether this dependency would actually lead to other more confusing behavior in different situations.

With that anticipatory bit of foreshadowing in place, I will proceed with the post. :-)

Mauli's question was straightforward enough:

Hi all,

I found this issue while using Vista RC1 as a client, and Windows 2003 as the server using Arabic-Saudi Arabia culture. Both have Whidbey SP1 (SP1.50727.360). On Vista, the calendar used for the ar-SA culture is different from previous versions.    On the client, I pass in the ar-SA short date string of Gregorian date 2004-12-27 to the server.  On the server side,  this string gets converted from its Arabic form into a Gregorian date. However, since the Arabic calendar on  the server is different from the client, I get back the wrong Gregorian date.  It seems that we should fix the same version of .net framework should always return the same calendar for ar-SA, no matter what the OS.  Is there something that I'm missing? Why wouldn't the same version of the .net framework always return back the same calendar?

Using .NET, find the Arabic date range to use - I used this code snippet:

CultureInfo c = CultureInfo.CreateSpecificCulture("ar-SA");
Thread.CurrentThread.CurrentCulture = c;
DateTime d = new DateTime(2004, 12, 27);
Console.WriteLine(d.ToShortDateString());
DateTime d2 = new DateTime(2005, 1, 5);
Console.WriteLine(d2.ToShortDateString());

Gregorian: 2004-12-27 to 2005-1-2005
Arabic DateTime.ToShortDateString()
Vista: "15/11/25" to "24/11/25"
Windows 2003: "16/11/25" to "25/11/25"

Uh oh, the worry here is that version 2.0 of the .NET Framework returns inconsistent results when it is run on a Windows 2003 machine with an Arabic (Saudi Arabia) user locale versus a Vista machine with an Arabic (Saudi Arabia) user locale.

Suddenly people aren't worried about the .NET Framework being consistent with Windows any more, are they?

Well, that is exactly what changed here. In Windows 2003 there is only the Hijri calendar, but in Vista the Um Al Qura (secular Hijri) calendar I have mentioned previously has not only been added, but it is also the default. And the calendar setting choice is one of those properties you can override, whether you are looking at XP/Server 2003:

where the default calendar is "التقويم الهجري" (Hijri Era) or in Vista:

where the default calendar is "تقويم ام القرى" (UmAlQura). One could always override the Vista choice if one wanted to, going back to that existing Hijri calendar.

Now of course the .NET Framework also added this new calendar, thus you can get either the UmAlQuraCalendar Class or the HijriCalendar class. And the new default in the 2.0 version of the .NET Framework is the UmAlQura calendar, but this too can be overridden, whether explicitly in code or implicitly by it being the default user locale with a different calendar setting.

So, if you are running code in the 2.0 version of the .NET Framework that uses the Arabic (Saudi Arabia) culture then you will get consistent results except in the case where Windows instructs the .NET Framework to use a different calendar (which it must do on Server 2003 and earlier since there was not yet an UmAlQura calendar to use.

Now I will be the first to admit that the few people who customize their date formats may have been confused to not see the changes in the .NET Framework. But in my opinion their problem is a lot easier to explain to people than this sort of calendar issue, because it is easier to say that Windows and the .NET Framework are separate but the .NET Framework results will be consistent within the same version.

Which is all water under the bridge now, except for every once in a while when someone hits this kind of issue again. :-)

This post brought to you by ت (U+062a, a.k.a. ARABIC LETTER TEH)