Localization Tips, Part 2: The Evils of Date Formatting

This is the second entry in a multi-part series about localization.

Every modern platform provides a mechanism for formatting dates. We've all dealt with people on the business side who prefer dates formatted as YYYY-mm-dd or dd MMM YY or countless other permutations. The slippering slope of date formatting is that once a date is formatted, it should be formatted correctly for each and every locale that the application supports.

Here is a sample of correct date formatting for 30 common locales:

Even after so many managed to agree on the Gregorian calendar system it's amazing to see the wide variety of date formats. Even if an application only needed to support a few locales, the developer would need to define a few date formats in each translation file and tweak as appropriate for that locale's conventions. I didn't know Romanians formatted their dates as 17.01.2013, did you? :)

While nearly every platform's date formatting APIs provide a way to explicitly set a date format, some also support the notion of "format styles." These styles define a short, medium and long style for formatting date and time for a given locale. Check out this example from the Flash Globalization APIs.

Specifying a date style of SHORT, MEDIUM or LONG is a very convenient way to ensure that dates are always formatted correctly for the current locale. Here's an example snippet of Flash code which prints out the MEDIUM version of the current date for the supported locales:

The output of this script is the same as the snippet of date formats a few paragraphs up. Pretty convenient stuff here. For added flexibility, a developer could also write code to support explicit date formats for certain locales and then fall back to a date style for other locales.

So before you format another date, dig a little deeper into their localization APIs to see what's available. You might be surprised what you find.