It goes without saying that if you develop software, you will need to deal with time. Yes, management of time, but I’m talking in a more literal sense: date/time data. No big deal, right? Old news, right? For the most part yes, but I have to say, it’s pretty alarming that I see developers still using (and parsing) a MM-DD-YYYY format for their date stamps. I shouldn’t see this. Ever.
There’s a standard to prevent it called ISO 8601. If you’re representing a date then you should store all your string-ish dates in the YYYY-MM-DD format, for a number of reasons.
- Correct sorting if used in a file system.
- Standard parse format for any common datetime class I can think of.
- Standard format for querying SQL databases.
- Other countries don’t use MM-DD-YYYY.
The last one is probably the most important. The others are definitely important, as neglecting the standard makes your code much more difficult to consume or interop with. But in this age of global computing, with SOAs and multi-culture apps, it’s critical that you adhere to the standard.
Case in point: An app I worked with had a license manager that used the typical MM-DD-YYYY format to store a date related to the customer’s purchase in the license file. Well, when a customer in China (with their system locale set to cn-PRC) went to use the app the framework parsed the date differently (because of their system locale) and the application wouldn’t unlock. The work around ended up being to force a culture change (Windows locale) for the thread used to validate the license (e.g. Thread.CurrentThread.CurrentCulture = new CultureInfo("en-US");). If the developer had used the proper ISO date format it wouldn’t have been an issue.
This is all magnified even more when you bring specific times into the picture as well. The standard addresses that as well. If you’re dealing with UTC time codes (which you should) just remember that you should represent everything on a 24-hour clock and in GMT (or Zulu time) like this: hh:mm:ssZ. If you want to use a specific time zone you do it by using an offset from UTC, like this: hh:mm:ss±hh[:mm[:ss]] (minute and second designations being optional, of course).
It’s practically a sin that I feel I even need to make this post, but if it prevents just one young developer from using their lazy conventional date/time format then I think it was worth it. If you want to take it the next step (like me) in your day-to-day writing, drop all those unnecessary “-st”, “-nd”, “-rd”, and “-th” from your date representations and write out dates like 06-06-2007, or 6 June 2007. It might be backwards from the ISO standard, but it’s a little nicer for humans to read, and if you know it’s only for a human, well then it’s not that big of a deal.
Edit: Funny, all this talk about time made me realize WordPress doesn’t update for daylight savings time. All my posts recent posts have been off by an hour.