Windows Mobile i18n fun

Looks like I’ll be doing some Windows Mobile development again since it is going to pay the bills for a bit.  Working with CloudSync on their GPS Logging utility.  The devices basically log the GPS data at 5 second intervals.  This data is then sent in batch to the servers for further processing.

The issue I worked on was making sure the data gets the server in a format that the PHP folks can recognize.  Internationalization (i18n) created a problem because the dates and numbers were being sent in a different format. In Chile for instance, the dates and numbers were not coming out as we expected.

currentLatitude.ToString("#0.00000");
// this came out as 0,00000

gpsTime.ToString("MM/dd/yyyy HH:mm:ss");
// This came out as MM-dd-yyyy HH:mm:ss

Apparently, .NET converts these for you based on the NumberFormatInfo object and the DateTimeFormatInfo objects.   I thought an easy way to correct this would be to set the current thread locale to be that of US so I could send the data in the expected format.  In the full .NET world, you could write something like this to accomplish it:
http://msdn.microsoft.com/en-us/library/system.globalization.cultureinfo(VS.71).aspx

Thread.CurrentThread.CurrentCulture = new CultureInfo("en-US");

Unfortunately, the CurrentCulture property on the thread object is not available in the compact framework.  Instead, you need to pass the culture object along with the format in the toString methods. You could create a CultureInfo object such as “en-US” and pass this, but .NET provides a better alternative.  The CultureInfo object has  a property called InvariantCulture.  Using this object ensures that the behavior is consistent across all the different cultures.

currentLatitude.ToString("#0.00000", CultureInfo.InvariantCulture);
gpsTime.ToString("MM/dd/yyyy HH:mm:ss", CultureInfo.InvariantCulture);


After doing this, it is exactly as one would expect.