I'm working with an automotive client that has a couple of data formats for some of their files. One is a simple CSV format and the other is XML using .NET's XML Serializer (nothing fancy). The CSV format is handy as it's easy for the engineers to quickly load it into Excel and view in a columnar format. The XML format was implemented as a much more "full featured" version of the data and contains additional metadata to describe the data. All of the maintenance of these files is very easy as we have a library for dealing with them.
One of the issues that was found early on in the development of the library was that, being a global automotive company, the CSV wasn't always "comma separated". Most european countries use the period (".") as a thousands separator and comma (",") as a decimal separator (i.e. three thousand dollars in this format would be "3.000,00"). A lot of work was put into trying to infer the culture of the machine that created the file so it could be read by any other culture. There were bugs from time to time and we found a few anomalies that made things more difficult. But it worked okay for the most part.
Recently, a decision was made (by people much higher than me) that going forward, the file formats (both CSV and XML) will always be in the English/US format (en-US). This made exchange of these files easier all around as our library wasn't the only application that read these files and some other apps were having problems with the multi-culture issue. Standardizing on the en-US format made things a lot simpler in the CSV read/write code as well as other applications.
In the XML code, I wanted to write some unit tests to make sure it also would always read/write in en-US format. To my surprise, no matter what I set my Thread's CurrentCulture to, the XML always came out in en-US format. I did some digging and found a thread about this on the ASP.NET forums. One particular post cleared things up for me. Martin Honnen (XML MVP) stated:
Well XML serialization uses a standardized number and date/dateTime format, the standard is the W3C schema datatype specification http://www.w3.org/TR/xmlschema-2/.
So don't expect XmlSerializer to pay attention to the thread's CultureInfo, it intentionally uses a standardized format to ensure you can serialize/deserialize independent of the culture/locale.
Sweet! Culture isn't an issue with the XML Serializer! Thanks Martin.