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!
So, what do you think? What is the best behavior here?
This post brought to you by ๙ (U+0e59, a.k.a. THAI DIGIT NINE)
# Marc Brooks on 19 Jun 2006 1:06 PM:
# Erno on 19 Jun 2006 2:43 PM:
go to newer or older post, or back to index or month or day