by Michael S. Kaplan, published on 2007/12/03 09:16 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/12/03/6643380.aspx
Over in the microsoft.public.dotnet.internationalization newsgroup, Marcel asks:
Hi NG!
I have a little question about the localization of a double.
If I use the CultureInfo "en-US" I have the following behavior:
1.) If I enter the value 2.5 into a textbox the double.Parse(text1.Text) returns 2.5 as expected.
2.) If I enter the value 2,5 into a textbox the double.Parse(text1.Text) returns 25...why 25 and not 2500. The , is the group-separator.
Is it possible to ignore these behavior to ensure the 2,5 and 2.5 will always be interpreted as 2.5 (like in the calculator) ? Or do I have to implement this behavior by my self?
Regards
Marcel
Unfortunately, there is no way to do this within the .NET Framework. There is only one decimal separator. And the grouping separator is treated as an ignorable thing, without it having zeroes added aiutomatically....
And applications like the Windows calculator are doing what they do all by themselves.
Though it is worth considering what you would want an application to do with strings like:
1,234,567,890.123
1.234.567.890,123
Noting of course that the Windows calculator does not do much that one might expect in many different cases.
When one writes a parser, one should definitely keep the weird cases in mind....
This post brought to you by . (U+002e, aka FULL STOP)
Aaron on 3 Dec 2007 1:06 PM:
If you're looking to uniformly treat '.' and ',' as digit separators, could you not query the decimal separator and then [[ decSep = cultureInfo.NumberFormat.NumberDecimalSeparator; x.Replace(",", decSep).Replace(".", decSep) ]]?
This begs the question, should you:
a) use 'CultureInfo.CurrentCulture', and the no-args double precision float parser, or
b) use 'CultureInfo.InvariantCulture', and hard-code decSep as '.', making the expression [[ x.Replace(",", ".") ]]
Most likely the former, since there are more parts to a number than just the decimal separator (say, the sign, digits, optional exponent character, currency symbol, etc) that may be cultureinfo-dependent. However, option (a) still feels wrong.
#aaron