Pop-quiz, hotshot: You have a project that’s due on 10/01/2014. How long do you have to complete it?
Yeah. Short-date formats are the devil.
For the first twelve days of the month, they have exactly zero reliability. This is not a quality that we like for a thing that is meant to store data—and potentially critical data, at that.
Additionally, they have cultural bias. If you read that due date as March first, it’s likely that you’re from North America. If you read it as January third, chances are you’re from Europe. Obviously, data types should be culturally agnostic.
So, in the late 1980s, the International Standards Organization set out to get some kind of consensus going on short-date formats. And out popped the standard known as ISO 8601, Data elements and interchange formats – Information interchange – Representation of dates and times, which states that dates shall heretofore be written as follows:
So let it be written, so let it be done.
As an added bonus, it builds-in some valuable organizing capabilities. Try this:
- Make a list of 100 random dates spanning a few years in Excel.
- Put them in a few different formats, including ISO 8601.
- Now sort them alphabetically.
Which one naturally sorts the dates in chronological order?
(As an aside, it makes the most sense to use dashes instead of slashes or dots because dashes will not confuse less-sophisticated parsers into thinking you’ve got escape characters or file extensions in the middle of your date.)
(As a second aside, I have a TextExpander shortcut,
sdate, that expands to today’s date in ISO 8601 format. You should set one up too.)
Of course, this being an international standard, no one actually follows it, and instead does their own thing.
If you choose to ignore ISO 8601—and even if you choose to implement it—please consider your design carefully, keeping your users in mind (remember, the person writing in a date may be different from the person reading the date). Users have a funny habit of running amok if you don’t try to somehow validate or constrain their input.
This is why web and app forms use slow, clunky date-pickers—they ensure that dates are being input correctly by, at a minimum, providing cues regarding what part of the date you’re entering.
The dropdown list goes from 1 through 12? You’re entering the month.
The same consideration is required for readers of a printed page. I recently received a form document from a company which contained the following table:
|Requested on||Required by|
So: how long do I have to fulfill this request?
The kicker is that this company almost certainly has internal procedures or software for filling out or generating this form. I, on the other hand, need more context. Consider the following modification:
Even if they’re not using an international standard or a fully-written-out long-date format, I know that this is needed by the tenth of January. No further discussions necessary. Clarity and consensus naturally flow from adding context.