Quick quiz: what glorious work of art was released on 08/01/09? Answer: this blog entry.
If you are in North America, and reading this sometime before Aug 1 2009 (US) or Jan 8 2009 (Canada), you might wonder what kind of stupid answer that is. (You might be wondering that anyway). Doesn’t that date just look wrong?
If you’re a programmer you’ve probably got my point by now. One of the most common causes of date conversion errors, and time conversion errors, and currency conversion errors, are “funny” regional settings. Back in the day, we used to have the luxury of decreeing that our programs would use such-and-such a format, and expect users to toe the line. After all, our programs weren’t mind readers — how could they be expected to know what the user was thinking when they entered “08/01/09″, unless we told them what to think.
Most modern programming frameworks have a more liberal approach. They grab date, time and currency formats from the operating system, then automatically apply them to strings that are being parsed until told otherwise. In theory, our code shouldn’t have to tell it otherwise very often, and us programmers just have to remember to stop hard-coding things like date formats and time separators and get them from the framework instead.
For example, we have a data entry program that allows the user to enter a time as just the hours: for example 15 for 3 PM. To check if the user has entered minutes, we don’t parse the string for “:”; instead, we get the time separator from the .Net Framework:
System.Globalization.CultureInfo cult =
System.Threading.Thread.CurrentThread.CurrentCulture;
return cult.DateTimeFormat.TimeSeparator;
I’m currently having to deal with 2 good arguments for hard-coding formats instead. The first is when you have to pass the data to a legacy system which handles date formats the “old school” way: by decree. Our Universe Basic APIs expect dates to be in “dd MMM yy” format, or sometimes “mm/dd”. That one’s not a big deal coding-wise, since the .Net ToString method accepts a format string:
return datDate.ToString(“dd MMM yyyy”);
The second argument is not so easily dealt with. The users of our .Net application are also users of our legacy application. We have beat them into submission to our hard-coded date, time and currency formats, so what is an eclectic French user going to enter when they see a .Net date input field. 08/01/09? Je pense que non. By habit, they’ll enter 09 JAN 08, or maybe 01/09.
So, do we hard-code our date parsing formats to match tradition, or loosen the shackles and allow them to enter dates the “right way”? I’ve gone with the latter approach, but it will turn out to be the “wrong way” if it results in a lot of incorrect dates entering the system.
