Question

I have a rather strange problem. I have a very simple application that reads some data from a csv formatted file, and draws a polar ‘butterfly’ to a form. However a few people in european countries get a very wierd looking curve instead, and when I modified the program to output some sample values to try and workout what is going on, it only gave me more questions!

Here is a sample of expected values, and what one particular user gets instead:

EXPECTED -> SEEN   
0.00 0.00  -> 0,00 0,00  
5.00 1.35  -> 5,00 1346431626488,41  
10.00 2.69 -> 10,00 2690532522738,65  

So all the values on the right (which are computed in my program) are multiplied by a factor of 10^12!! How on earth can that happen in the CLR? the first numbers – 0, 5, 10 – are just produced by the simple loop that writes the output, using: value += 5.

The code producing these computations does make use of interpolation using the alglib.net library, but the problem does also occur with 2 other values that are extracted from xml returned from a http get, and then converted from radians to degrees.

Also not exactly a problem, but why would decimal values print with commas instead of decimal points? The output code is a simple string.Format("{0:F}", value) where value is a double?

So why on earth would some values be shifted by 12 decimal places, but not others, and only in some countries? Yes others have run the app with no problems… Not sure if there is any relevance but this output came from Netherlands.

Answer 1

Different cultures use different thousands and decimal separators. en-US (US English) uses “,” and “.” but de-DE (German German) uses “.” and “,”. This means that when reading from or writing to strings you need to use the proper culture. When persisting information for later retrieval that generally means CultureInfo.InvariantCulture. When displaying information to the user that generally means CultureInfo.CurrentCulture.

You haven’t provided the code that reads from the CSV file, but I imagine you’re doing something like double.Parse(field) for each field. If the field has the value “5.0” and you parse it when the current culture is de-DE “.” will be considered a thousands separator and the value gets read as 50.0 in en-US terms. What you should be doing is double.Parse(field, CultureInfo.InvariantCulture).

All of the Parse, TryParse, Format, and many ToString methods accept an IFormatProvider. Get in the habit of always providing the appropriate format provider and you wont get bitten by internationalization issues.