Most of us folks in the United States are familiar with the MM-DD-YY short date system (e.g., 6/28/13 for June 28, 2013). It's familiar, but if you stop to think about it, it really doesn't make very much sense. The digits of least significance are in the middle, not at the beginning or at the end. The only reason the order makes any sense at all is that it matches the way we say dates (May 23, 2013).
In this article, I will explain the reasons the short date formats most people use are problematic, then introduce the alternative, YYYY-MM-DD format, and explain how it solves the problems of the other formats.
We will first remove MM-DD-YY format from serious consideration as the best short date system because the parts of the date are not in order of significance, making it illogical and confusing and preventing it from sorting easily. (Also, I wouldn't be writing this article if the system prevalent in my country was the best, would I?)
Many if not most countries use a DD-MM-YY system. This does have the advantage of having the parts in order of significance (smallest first, then middle, then largest), and it matches another popular way of writing longer dates (23 May 2013). However, there are two major flaws with this system too:
- The most significant part is at the end, not at the beginning. This makes it sort really nasty on a computer. If you have some folders named with dates in DD-MM-YY format, for instance, this is how they'll sort:
- 05-07-07 (July 5, 2007)
- 15-5-13 (May 15, 2013)
- 17-8-12 (August 17, 2012)
Obviously that's about as far from chronological order as you can get; the sort is essentially random, provided your list of dates uses all days equally. MM-DD-YY doesn't handle this situation perfectly either, but at least it sorts the months in order, so it's a little bit easier to find things.
- DD-MM-YY is indistinguishable from MM-DD-YY in many cases. By my calculation, this happens about 36% of the time (see why). If the day number is above 12, you can tell the difference if you're paying attention, but if it's below, you just have to guess which it is supposed to be based on the context.
12-22-09: unambiguously December 22, 2009 (MM-DD-YY)
18-12-09: unambiguously December 18, 2009 (DD-MM-YY)
12-11-09: could be December 11, 2009 or November 12, 2009This is not a small problem. This past year, a friend of mine thought a huge examination was going to be a full week after it actually was because the schedule was written in DD-MM-YY format and he assumed it was MM-DD-YY.
There is a better format: YYYY-MM-DD. This arrangement solves a number of problems:
- With the four-digit year coming first, the system being used is clearly identified. (If you're thinking sharp, you might notice that theoretically it could still be YYYY-DD-MM, but that would be a ridiculous system and I've never seen it used anywhere.) A four-digit year also avoids the Y2K problem when the dates are used in software.
- The system is big-endian, with the most significant part first. This makes the dates sort correctly with no special code or care on the part of the user.
- The parts are arranged in order of significance, so the order is more logical than that of MM/DD/YY.
- The system is an ISO standard (8601). If you like reading about standards on Wikipedia, you can do that here. Conforming to standards, when there's no solid reason not to, is just a good idea (especially if you're writing software or making official documents that involve dates) – everything is more likely to work out nicely in the long run.
There are only two real issues with YYYY-MM-DD, and they're both less serious than those of the alternative formats. The first is that some people aren't familiar with it. This can be an issue, but it's considerably easier to figure out the correct date written in YYYY-MM-DD format if you're not familiar with it than one written in DD-MM-YY or MM-DD-YY when you're used to the other order (and believe me, there are many Americans who have never heard of DD-MM-YY and are baffled when they run into it). The other is that while the mathematically most significant part is first, the year is often the part of the date that you care about the least, and you have to read through it before you can see the more important month and day. However, in the long term, this is turned right around and the year is far more important than the day or month, so overall I don't think this is a particularly important consideration.
I converted to using YYYY-MM-DD some time ago. I still use MM-DD-YY if I'm asked to write a date on a form or I'm afraid other people won't be able to read it, but if I date something for myself I never use it anymore. You may not want to use YYYY-MM-DD for everyday things, but you should always use it in filenames, spreadsheets, or databases because of the sorting considerations – you'll be thankful later if you need to sort the dates.
A couple of picky details:
- You should always write leading zeros. For instance, January 1, 2001 is never 2001/1/1, it's always 2001/01/01. Leading zeros help make sure computers sort correctly; even if you're not planning to put the dates into a computer, it's a good idea to do it now to make sure it isn't forgotten if they ever are. They also ensure the date has a consistent number of characters, which makes columns of dates line up much more nicely (yeah, I'm pretty picky about this kind of stuff).
- The ISO standard specifies a hyphen (-) as the separator. I personally tend to prefer the look of slashes (/), so even though it's not the standard, I usually use them. Dots (.) also work well, especially if you're naming folders or files (no filesystem that I know of accepts slashes in filenames). I always use hyphens if I write any computer code that involves dates, though – following the standard exactly is much more important there. Long story short, if you want to be certain your date is unambiguously- and ISO 8601-formatted, use hyphens, but if the date is just for you, I give you permission to use a separator you like better.
Finally, here's an xkcd comic on the problems of date formats and ISO 8601:
(Used under CC BY-NC 2.5 license from http://xkcd.com/1179/.)