Parsing date formats with dd/MM/yyyy or MM/dd/yyyy?

I was angry and frustrated. The developer tested his code, and it failed. When he sent it to me for help, I tested it, and it worked. Isn’t it supposed to be the other way around? Someone writes the code and it works for them, but when it’s reviewed by you, it fails?

That developer couldn’t get the date selection right. I wrote a web control library which includes a date selection widget. When I designed it, to simplify things, I hardcoded the date parsing to be dd/MM/yyyy format (I’ll explain my choice later on).

What happened was, the developer either got the yellow screen of death (if you’re working in ASP.NET, you know what I’m talking about), or the day and month were swapped.

Finally, I asked him if his computer settings had MM/dd/yyyy as the default short date format. And if it was, to change it to dd/MM/yyyy. It was, and he changed it, and the code worked.

The default date setting on computers running on Windows is MM/dd/yyyy format. I change it to dd/MM/yyyy format because Singapore uses that format. And my users’ main business involves a big company residing in United Kingdom, which also uses the dd/MM/yyyy format.

Here’s how you change the settings. Go to Control Panel, and click on “Regional and Language Options” or something named similarly. You’ll get something like:

Regional and Language Options

Click on the “Customize” button to get:

Customize Regional Options

In the “Short date format” dropdownlist, enter “dd/MM/yyyy”. You may not find it under the dropdownlist options. This is what some people don’t know: You can type “dd/MM/yyyy” in the dropdownlist. Click “Apply” button, then “OK” button, and you’re set.

Here’s some code to test your changes:

System.Globalization.CultureInfo c = new System.Globalization.CultureInfo("en-GB", true);
DateTime dt1 = DateTime.ParseExact("05/08/2009", "dd/MM/yyyy", null);
DateTime dt2 = DateTime.Parse("05/08/2009");
DateTime dt3 = DateTime.ParseExact("05/08/2009", "dd/MM/yyyy", c);
DateTime dt4 = DateTime.Parse("05/08/2009", c);
Console.WriteLine(dt1.ToString("D").PadLeft(30) + " | " + dt1.ToString(c));
Console.WriteLine(dt2.ToString("D").PadLeft(30) + " | " + dt2.ToString("dd/MM/yyyy"));
Console.WriteLine(dt3.ToString("D").PadLeft(30) + " | " + dt3.ToString("MM/dd/yyyy"));
Console.WriteLine(dt4.ToString("D").PadLeft(30) + " | " + dt4.ToString());

Did you get the values you expected?

Here’s the comparison output from the American MM/dd/yyyy and British dd/MM/yyyy format:
Regional settings test output

Note that the code remained the same. Only the regional settings were changed.

So what I found out was that, as long as you explicitly state the date format (or use a culture setting with your desired date format), it works whether you’re parsing in the date string, or printing out the date.

Despite changing the settings, I still had a date format issue which I asked on StackOverflow. It was some time ago, but I didn’t get a satisfactory answer. Then again, it was my colleague’s problem and he’s fine with the weird behaviour… The problem could be because he didn’t explicitly set the output format, which displayed the wrong date on the screen, even though the regional settings are correct on the web server.

  1. Eric

    This is why I’m a fan of the ISO 8601 standard (http://en.wikipedia.org/wiki/ISO_8601). Since it starts with a four digit year, it’s fairly clear when it’s being used. Furthermore, it sorts correctly without having to resort any special date sorting (and date recognition) algorithms.

  2. Vincent Tan

    I like that YYYY-MM-DD format too. Clear on which parts correspond to which values.

    I *do* have something to say about the Wikipedia article you gave:

    “Date and time values are organized from the most to the least significant: year, month (or week), day, hour, minute, second, and fraction of second.”

    Depending on one’s temporal urgency, one might find the current minute and hour to be *more* significant than the month or year… hohoho…

  3. Eric

    I’m pretty sure they meant significant in the same sense as ‘significant digits’: more significant numbers carry more weight. In this case, it basically means that there is more time in one unit of a more significant unit than there is in one unit of a less significant unit.

    Still, at least the art of equivocation is alive and well.

  4. Vincent Tan

    I was kidding, Eric. 🙂 I know what you meant.

    I wonder what happens when we hit the end of year 9999? Do we create a more significant time component, say, the era or something?

  5. Matt

    If you uses the example below System.Globalization.CultureInfo.CurrentCulture as your culture it seem to pick the correct format with you having to modify any setting on the server machine. System.Globalization.CultureInfo.CurrentCulture seems to hold most of the regional setting info

    Dim myDate as Date = Date.Parse(datestring, System.Globalization.Cultureinfo.CurrentCulture)

    http://www.xtremedotnettalk.com/showthread.php?t=35839

Comments are closed.