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

by Michael S. Kaplan, published on 2006/09/29 03:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/09/29/776495.aspx

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);
DateTime d2 = new DateTime(2005, 1, 5);

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)

# Adam on 29 Sep 2006 4:27 AM:

Hang on - I thought that one of the goals of .NET was for it to be platform-independent so that implementations on other systems (e.g. Mono on Linux) would be able to run .NET applications just as well as the MS implementation on Win32.

What the *hell* is it doing being more consistent with Windows than itself?

Or was the "platform independence" thing just a big marketing lie to get people who were worried about vendor lock-in to develop for it? Only they're screwed now.

And MS wonders why no-one trusts them!

# Michael S. Kaplan on 29 Sep 2006 9:05 AM:

Hi Adam,

Note that they both have the same capabilities -- it is just that they are responding to external stimuli (in this case different locale settings). The complaint is about like complaining that CurrentCulture returns different results if you have different locale settings....

In other words, the complaint is specious, as is yours (just a little bit). :-)

# Dean Harding on 2 Oct 2006 1:10 PM:

Well, I think the way it works is correct. If you're going to display the data to the user then you should use whatever settings they choose.

If you're going to trasfer data between processes, then you should use a non-culture-aware method anyway.

# Aldo.Net on 4 Oct 2006 8:01 PM:

Agree, to some degree (pardon the rhyme :-)
Can't it be that Windows is too busy shipping improved versions (and assuming everyone will use the latest) and not giving enough importance to backward compatibility?
Not a flame - just a thought based on some observations of the facts. Some breaking changes are really a must, regardless of the pain they cause - is this one of those?

# Michael S. Kaplan on 4 Oct 2006 10:58 PM:

The change to support the new government mandated Saudi calendar in both Windows and the .NET Framework is very much a change for the sake of the standard, actually....

# Michael S. Kaplan on 4 Oct 2006 10:59 PM:

Additionally, the notion that we could never ever add a calendar even if one were needed in a particular market is also pretty unpalatable.

The user's preferences and choices are being respected by everyone other than the developer.... :-)

Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.

referenced by

2010/03/18 Whether the currency sign is right or wrong could be something of a crapshoot

2008/05/14 Windows is too busy being consistent with the user to be consistent with itself!

2007/06/26 Behold the [non-fa-IR default] PersianCalendar class

2006/10/15 Compatibility is inconsistent; consistency is not compatible...

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