Friday was a dead line for one of our applications. As usual there were some late bugs detected. One of them caused us a terrible headache. I was pulling out a string from the database representing a float number “1.609”. I had to parse that string on my code and convert it to float, Double type in VB.NET.
The string was converted fine for all the cultures in the application but French.
I was complete puzzled, aren’t doubles the same in all cultures? Isn’t mathematics the same? The Earth is round, the Pi number is the same no matter what language you speak, then why this statement will throw an “Expression cannot be evaluated” exception when the Current Thread culture is fr-FR????? Nonsense.
intUserRadius = Round(intUserRadius * Double.Parse(strRadiusUnits)
The same happened with
intUserRadius = Round(intUserRadius * CDbl(strRadiusUnits)
Both Functions failed on French, it seemed that French doubles are not the same.
Ok, the decimal separator in fr-FR is a comma and not a point, but the strRadiusUnits string is a string that is not culture biased and has a decimal point as separator.
It looks like this parsing functions were expecting a comma instead of a decimal point, so the following work around had to be applied:
intUserRadius = Round(intUserRadius * Double.Parse(strRadiusUnits, CultureInfo.InvariantCulture))
So, beware of the string parsing when you’re handling Global applications.
I got these two replies from a developers list:
Mathematics is the same in all cultures, but the character-based
representations of them may not be.
English is 1.5, others are 1,5
The default behavior Microsoft decided upon was basically “you can write
lazy code to your own current culture and not have to worry about
globalization”. This means that people who use 1,5 to represent one and a
half don’t have to do anything to write code to parse their own cultural
representation of the value. Once you get into multiple cultures, you have
to stop being lazy and use the supplied culture-aware overloads.
In your case, you have an English-centric view of data in your database
(1.609) which just so happens to be the “invariant” culture Microsoft
decided upon in their libraries. So to parse the data you’d need to use
Thanks Adam for the reply.
You are parsing *from* a string, and “1.609” as a string
does not match the local culture. Any and all conversions
to/from strings need to be scrutinised for culture issues.
Far better would have been to store & retrieve a double
value from the database, rather than relying on using
strings as an intermediate format.
Thanks John for that reply.