Sankofa

Today’s post is a simple reminder that Localization is a dirty job!

DateTime.Parse() will break your software on localized system

So, after some time working on the migration project, we finally released a stable Release Candidate. While the Test Team is still running their Critical Regression testing (that’s the final test before release) on the release candidate, I was transferred back to the Localization project.

My current task is to make a certain web application work with the localized version of our product which is running on a localized version of Windows.

So far, there are 8 tracks filled against this certain web application. A quick look at the tracks revealed a common problem:

“String was not recognized as a valid DateTime.”

Along with that error message, the exception also gave the error’s stack trace. Lucky for me, it already gave the name of the offending namespace (but no line number, weird.) So I dig thru the code and found this on a simple Get/Set class:

private static DateTime _offset = DateTime.Parse("04/21/2007 1:45 PM");

There are a couple of things that tickled my curiosity. Firstly, what is the purpose of this offset and why is this certain date chosen as the offset? Secondly, why is there a hardcoded date on this code? Finally (and most importantly), will DateTime.Parse() be able to parse the standard US date format (MM/DD/YYYY) in a localized version of Windows (running a Russian locale)?

The first two questions were never answered (the developer who made it is no longer connected with the company). But the answer to the last question was given (more like demonstrated) by my manager using Iron Python. My manager loaded a copy of Iron Python into a running Russian Windows Server 2008. He then launched Iron Python’s Command Line Interpreter for .NET (ipy.exe) then typed the following commands:

import System
DateTime _offset = DateTime.Parse("04/21/2007 1:45 PM")

Shockingly, the Parse command thrown an exception! DateTime.Parse() is dependent to the current CultureInfo of the machine! Since the Russian version of Windows uses the default russian date format (ISO 639.1) which is DD.MM.YYYY, DateTime.Parse() was not able to “understand” the supplied date in standard US format MM/DD/YYYY.

As a simple fix, instead of parsing the date and time, I passed the values as argument like so:

private static DateTime _offset = new DateTime(4,21,2007,13,45,00);

Problem solved!