Correct? Intuitive? Both? Neither?

by Michael S. Kaplan, published on 2006/06/19 09:21 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/06/19/636785.aspx

It was way back in April of 2005 (in the post Is Whidbey's international support finished?) that I pointed out how it would be possible in future versions for the .NET Framework to properly support parsing/formatting of digits used by other locales now that the properties had been added to the .NET Framework.

But if you add to that the issues implied by The Phantom of the Digits, there is a serious potential for such a future version feature to do things in a way that is either non-intuitive or incorrect....

As an example, let's take the Thai digits 0-9 (๐๑๒๓๔๕๖๗๘๙). They can exist independent of locale, or if my default user locale is Thai and my digit substitution setting is 'National' then the ASCII digits (0123456789) will actually appear like ๐๑๒๓๔๕๖๗๘๙.

So if one is parsing, should the parse results ignore the culture-specific behavior of the user looking at the data? It would be quite easy to do this (since that is what is in the underlying data anyway).

But turning the question around -- what should formatting do? Should it also ignore the culture-specific behavior?

Now does the answer to either or both of these questions change if the IFormatProvider is passed and it is a NumberFormatInfo of the culture in question? It seems like it may not be entirely intuitive to ignore culture-specific behavior such as the appearance of digits when the cultural info is passed to the methods, whether it is the right behavior or not....

Its seems like there is a rich opportunity to either not be correct or not be intuitive here!

The potential for this digit substitution is one of the reasons I'm such a strong advocate for getting things right and using InvariantCulture when emitting non-human-read strings. In the Atlas Control Toolkit, people are STILL getting it wrong and emitting/parsing things like the size of a control using CurrentCulture (usually implicitly).

If you guys ever do all that cool digit substitution, like you could (maybe should?), then those controls are going to break. Pow.

Michael,

I have been struggling with something that is quite similar (I think)
Take a look a this code:

DateTime dt = DateTime.Now;
CultureInfo ci = new CultureInfo("he-IL");
string date1 = dt.ToString("dddd/MMMM/yyyy", ci);
string date2 = ci.DateTimeFormat.MonthNames[new HebrewCalendar().GetMonth(dt)];

Guess what date1 and date2 contain... Well they didn't do what I suspected (or rather hoped for...)

And it even gets better when I add:

ci.DateTimeFormat.Calendar = new HebrewCalendar();

I am still looking for a way of converting "june 16, 2006" to Sivan 23, 5766

Why does an instance of a HebrewCalendar return 5766 when I call GetYear(dt) and at the same time returns a Gregorean month index on GetMonth(dt) that is not an index into the Hebrew DateTimeInfoFormat.MonthNames array.

I wrote my own method to return the Hebrew month names.(even included a calculation that pinpoints the 'exact' sunset for a given latitude and longitude to make the date switch at the right time) but I can't help but think that the .NET framework should do this for me...

Am I looking in the wrong direction?