Serialize and then Deserialize DateTime using different formats

Question

I am working at a Windows Phone 8.1 app and I have to handle the following globalization-related issue :

I am getting some DateTime value from a service and serialize it in my app for later use. The default culture is used (for example, en-US, with a datetime format MM-dd-YYYY).

If the OS changes its language, the app will use its best matching culture (let's say it will use one with this format : dd-MM-YYYY).

At app launch, when settings are to be retrieved, the app will crash because the DateTime vlue was serialized using a different format.

I am reading articles for this topic and mostly I found and read about saving (in my case serializing) a DateTime using a specific culture format. What about deserializing it afterwards, using a different format? I am unsure how to handle this.

Answer 1

Cultures are for humans. You should, in general, use them for displaying information to humans, and for receiving information from humans (eg when they type something into an edit field). Serialization is a completely different scenario, and calls for a completely different approach.

Note that a computer does not care what culture data is in per se, but does need you to be consistent.

In particular, when you format (eg string.Format() , DateTime.ToString() , etc.) a value, you should use an overload that allows you to provide a CultureInfo instance, and pass CultureInfo.InvariantCulture (or in some unusual cases, a specific , hard-coded culture). When parsing information that you've formatted this way (eg DateTime.TryParse() , etc.), you should again use an overload that allows you to provide a CultureInfo instance, and again pass CultureInfo.InvariantCulture (or in those unusual cases, the specific hard-coded culture you used to format the text in the first place).

This ensures that your code creates consistent text from your data, and then can later reliably interpret that text, regardless of what culture settings the user is using. The serialized data may or may not make any sense to a human trying to read it; but that doesn't matter…the data wasn't formatted for the user's benefit, it was formatted for the computer's benefit.

If for some reason, you need the text to be formatted in a way that matches the user's current culture settings, and still have the requirement that the data can be parsed later by code running in an environment with unknown culture settings, you must include the name of the culture as part of the serialized data, so that the code running later can use the correct CultureInfo object for parsing (and again, specify it explicitly, rather than using the current culture settings). Noting, of course, that if you do it this way, even the human trying to read the data may have problems…for a human being, knowing the name of the culture does not necessarily lead immediately to being able to understand data formatted using that culture.