Tuesday, June 5, 2007

The Dating Standard Dilemma

I never realized what a problem date formats could be.

One of my clients has a worthy obsession with templates and naming conventions, including date-stamping all docs. To that end, they employ the non-standard US date format: mm/dd/yy at the end of all file names. Since they don't use any separators (hyphens, etc.) this results in strange numbers at the end of documents (e.g. 060407) which are not immediately recognizable as dates. Frankly, I don't see the this kind of confusing date stamp adds any real value.
Anyway, being a bit of a standards-junky myself, I've now switched to using ISO 8601 format (CCYY-MM-DD) for all dating of my business documents, invoices, proposals, etc.

A couple of interesting links on the subject:

"11 Good Reasons to Use ISO 8601"
http://www.saqqara.demon.co.uk/datefmt.htm

"FAQ: Date formats"
http://www.w3.org/International/questions/qa-date-format

The Date Interpretation Quagmire"
http://www.w3.org/QA/Tips/iso-date

This works pretty well for documents where the date is just data or metadata, in spoken and written word I still lean towards writing out the date as it would be spoken (e.g. June 5, 2007) and avoid abbreviations altogether. This makes even better sense when working on a project that will later be localized.

Oddly, this is a HUGE problem in software training/localization and I'm astonished all software isn't using the ISO standard. A project I'm working on now is actually French software being translated to English where they've had to switch from the European DD/MM/YYYY to the U.S. MM/DD/YYYY. If they had just used the ISO standard from the start, there would be no confusion to begin with and a lot less work to do.