There have been discussions about the order of DD, MM, YYYY, but never really any discussion about why designers choose to use YYYY over YY (for instance, 01/01/2017 rather than 01/01/17).
Any idea why there is such a preference?
I can briefly think of some instances when including the entire YYYY is useful based on context, but assuming that the system I'm designing won't be dealing with century old objects, I wouldn't need the full YYYY. Am I right? Isn't it fine to just use YY then?
There is no universally good answer to this question, but there are definitely two pros of YYYY:
In other words:
Notation Possible interpretations:
----------- -------------------------
09/10/11 Four:
September 10th 2011
9th of October 2011
2009, 10th of November
2009, October 11th
09/10/2011 Two:
September 10th 2011
9th of October 2011
2009/10/11 Two as well:
2009, 10th of November
2009, October 11th
So, as you can see, by telling the User where the year is you limit the concern. Should the date be from a year which ends in a number higher than 31 (which is the highest number possible in the other fields), something interesting happens:
Notation Possible interpretations:
----------- -------------------------
09/10/33 Two:
September 10th 2033
9th of October 2033
However, the above interpretation requires the User to first analyse the contents of the string, so it increases the cognitive load significantly. The thinking would be:
"Is 09 the year? Not sure. The middle one is not year. Oh, 33 is the year. So 09 must be the day or month."
Of course this happens in a blink of an eye (Well, two of them. Well, three), but it is still a cognitive load and if Users need to deal with a lot of dates in this form, they may need to go through the same unwelcome process of searching for the year many times until they learn. And they should not have to learn.
And for these you do not need to bother of the contents, you can easily tell where the year is just looking at the obscured string:
Now we get to the real culprit why the dates are so unclear: month versus day. Let us say, we have solved our problem with the year and still need to tell one from another here: ▓▓/▓▓/▓▓▓▓
Notation Possible interpretations:
----------- -------------------------
09/10/2033 Two:
September 10th 2033
9th of October 2033
For me, the gradual approach, where the time units consistently goes from lower to higher (so: DD/MM/YYYY) or the other way (YYYY/MM/DD) makes much more sense. Unfortunately, in a system that Users only approach from time to time it does not matter if you use this approach, because they will not remember that you have used it.
On the other hand, the MM/DD/YYYY format for the date is common in the US, Canada, Greenland, Philippines and several African countries (source), as an abbreviation of the way the date is pronounced: "September 10th, 2017". However, as there is also another pronunciation allowed this brings only confusion.
To get out of this madness you may consider changing MM to the textual version of it (e.g. shortened: OCT/10/2017 or 09/SEP/2017), but in this case you fall into a problem of translation for international Users.
One situation when you do not need to bother about the notation is a situation when Users deal a lot with the date data, mostly in professional way. Two examples I can give you out of my head would be financial analysts (observing changes on the market) or photographers dealing with a lot of photos named using some convention they know by heart. If they know it by heart, this is not a concern.
Another situation when the importance of what is year in the date becomes less important is when Users are more oriented on "now". Facebook is a good example.
Saving space may be sometimes a really important factor for making decisions. Again, in dashboards containing a lot of data, the year may be either completely obsolete or may need to be truncated. But I believe these dashboards fall into the basket of professional usage most of the times, so no need to worry about them too much.
In some cases, you may face a situation when you need to combine the date into one big chunk of text. For example, the naming convention I use for photo files is YYYYMMDD_HHmmSS.ext, (e.g. 20170911_113426.RAF) This, again, falls into the "pro" usage basket; however it also provides means for sorting by date without needing to worry that the date attribute of a file would change (e.g. because it was moved to a file system that does not support this kind of attribute, or edited in an app that would clear it). This usage scenario brings two conclusions:
Do your Users know the system by heart? Do they use the date attribute on everyday basis? If so, do not bother about the recognition where the year is, but consider additional things like sortability or uniqueness (e.g. 1911 from 2011 when the date scope is wide.)
Do your Users approach the date attribute only occasionally? If so, provide higher recognition for what is what in the date without high cognitive load from their side: expand the year to four digits, make it clear where the month is. Unless space is critical for you, in which case you need to prepare for trade-offs.
As many comments below refer to ISO-8601 standard, I would like to explain why I have not added it in my original answer.
I believe that the word "standard" has a twofold meaning: a norm and a convention.
A a convention is a common approach to something that is used by a limited group of people. Regarding a specific topic like this one, there can be (and there usually are) various conventions, out of which one can contradict another (again: like in this case). And what is more, most of the conventions contradict the norm and the norm contradicts most of the conventions.
Conventions have their historical, linguistic, practical etc. roots. In case of date conventions, for example the MM/DD/YY comes from American way of saying the date as "November 5th, 2008" whereas somewhere else it can be different.
Now to the norm.
A norm has a role to deny most of the conventions used so far, to replace most of them. It can be one of the conventions that has been selected as a norm, but most of the conventions need to be denied if just one has to stay. A norm usually is well thought out. The norm in this particular case makes a lot of sense, as every-next-unit in it is smaller than the previous one (and this allows easier comparison between dates, sorting by date as a text string etc.).
There are definitely two ways to go from here.
One is to push the norm until it is used everywhere, in long term providing coherence in the standard used all over the world. Forcing people to use something different from what they have always used has got its drawbacks, and this way is - to some extent - against usability.
The other option is to adapt to the local conventions people understand. Having derived from cultural, linguistic, practical reasons, the conventions feel locally more adequate. But at the same time, when people using some convention also meet the other ones while browsing the web may become confused when they see something different from what they got used to, and hailing this approach is also - to some extent - against usability.
This way, I still believe that there is no universally good answer to this question, and it may not appear any soon. What can be done for now is limiting some bits of confusion - like in case of the year being written as four, not two digits.
01/10/17, how do they know which format is being used? Of course you can solve that with 01 Oct 17 but then you have added a new internationalization problem. I agree with using the ISO format. The unfamiliarity problem is smaller than other problems, and the more it is used, the more this problem goes away.
As a rule, it's never OK to use a 2-digit year. If you can prove that using a 4-digit year will cause thousands of babies and cute fluffy bunnies to die horribly, that could be an exception to the rule, but probably not.
I have seen hundreds of costly process failures simply because a programmer thought it was perfectly OK to use a 2-digit year or a local date idiom this time.
But I have never once seen a program or process fail due to the choice of YYYY-MM-DD ISO 8601 Standard Date Formatting. It's always the right choice. Take this advice to heart, and you'll never regret it.
The YYYY-MM-DD standard form is equally comprehensible to people from any country, of any age - even ones that were born in countries where the traditional format is something objectively braindead, like MM/DD/YY or DD/YY-MM. It also sorts correctly without reformatting, a bonus feature!
Take this example: 01/02/07.
At first look, it could be anything. Now, let's make it YYYY: 01/02/2007.
Quite a bit of difference, right? This is one of the main reasons for the YYYY format. Very few datapoints are in 2-digit / 2-digit / 4-digit format, and this helps avoid a bit of confusion.
Taking into account that this question was asked in the UX section of stackexchange, I would assume that the answer should focus on the user's expectations.
I have personally been working in a large Y2K project, and I would expect that software developers have learned their lesson from such projects. However, there still seems to be a certain disagreement about what that lesson is. It is not that 2-digit years are always evil.
It is a historic misconception that the primary reason for storing year values in 2 digits was to save storage memory. The truth is that the users wanted 2-digit years in their interface mainly because they did not want to enter unnecessary data. The developers' fault was not to differentiate between the user interface data and the stored data. It would have been perfectly okay to use 2-digit years in the user interface, as long as they were stored in 4 digits. If done so, any ambiguity would have been detected instantly instead of years later.
As a consequence, when it comes to UX, I would answer that it is perfectly acceptable to use 2-digit years in the user interface, as long as
To illustrate 'given context':
When you are not dealing with century old events - it will make perfect sense to use YY instead of YYYY.
Even Stackexchange follows the same pattern:
MM/DD or DD/MM does change continent wise, but the YY or YYYY remains the same for entire world (At least in countries that use English as official language).
ISO 2014, though superseded, is the standard that originally introduced the all-numeric date notation in most-to-least-significant order [YYYY]-[MM]-[DD]. The ISO week numbering system was introduced in ISO 2015, and the identification of days by ordinal dates was originally defined in ISO 2711.
ISO 8601:2000 allowed truncation (by agreement), where leading components of a date or time are omitted. Notably, this allowed two-digit years to be used and the ambiguous formats YY-MM-DD and YYMMDD. This provision was removed in ISO 8601:2004.
The YY options are completely valid
I thought the argument about yyyy rather than yy had been dealt with in the run-up to y2k? There are almost certainly people reading this who will be alive to see 2099 turn to 2100, and there are almost certainly coders who have failed to learn the lesson whose code will go horribly pear-shaped come 2100 (when it will still be in use by somebody, somewhere).
Also, people are living to beyond their 100th birthday in ever-increasing numbers. Assuming that a user-entered date of birth is always less than a hundred years ago is likely to be a very poor assumption in the near future. I've already read of letters addressed to the parents of 104-year-old pensioners concerning the selection of their first school -- legal threats concerning the non-attendance of these pensioners at primary school are certain to follow soon!
Using YYYY over YY ensures it is immediately obvious which of the three fields represents the year. This resolves some ambiguity, not just between different centuries, but also between date formats. However, DD/MM/YYYY is rarely an acceptable representation.
For display purposes, you may want to use a long format, e.g.: 'Tuesday 4 April 2017'. It is clear and unambiguous, but takes up a large and variable amount of space and may require translation into other languages.
For numerical representations, always use YYYY-MM-DD (ISO 8601), which is guaranteed to be unambiguous, is an ISO standard, is easy to parse by both computers and humans (even those accustomed to other formats), requires no localisation and can be ordered chronologically by lexical sorting.
Advantages of YY:
Disadvantages of YY
You should weigh advantages and disadvantages against each other based on your use case - saving these 2 letters is suddenly important if the next best alternative is scrolling on a LED display. Saving .2 seconds of typing can be quite useful in a workflow that needs a user to enter 1'000 dates a day. But in pretty much all other cases the balance tilts the other way.
The Y2K changeover created lots of work, which was good from a monetary view - but it was really boring work. I wont live to see 2100, but please don't make life boring for our heirs...
(Not clear enough? From ~1985 to 1999 we all spend many hours of work upgrading systems where developers who lacked foresight had used 2-digit dates. Please don't repeat that error.)
Most of the people uses DD/MM/YYYY format. Based on region/country format is varying. Date format by country
For timestamps, in file or directory names I always use YYYYmmdd that way normal lexical sorting (e.g. ls -l command) always lists stuff in the correct sequence. Neither mmddYYYY nor ddmmYYYY has that property.
In handwritten notes, I sometimes use just YYmmdd for convenience and when I won't be confusing the century.
Of course in the year 9999 this notation will once again cause much angst.
99991231, A100000101, ... A999991231, B1000000101, ... B999999-12-31 this allows for 30-digit years that will still sort correctly. But I also have some application logs in the *YYMMDD.log format, which doesn't bother me awfully much, as the logs aren't retained long enough to be a problem.
Apr 5, 2017 at 17:46
It depends on what you're trying to achieve. In some cases (perhaps more than you think) users may need to see a 4-digit year, while in others a two-digit year is adequate. It's not just century-old events that you have to consider, and it depends how you expect your users to input dates. Here are some examples:
A bit of opinion: this clarity/flexibility beats saving space.
On the other hand it's possible to work in a much more restricted time-frame. If you're selling theatre tickets, and events can only take place within the next year or so, users only need to see a two-digit year. Even past orders would make complete sense with only YY in this case.
Honestly, when it comes to dates, I always use the 3 digit representation for the month, just because Americans...
As many have pointed out 09/10/11 could be 9th Oct or 10th Sep, whereas if you have 09/Oct/11, all users know what you are looking for.
Either that, or have some (obvious) way for the user to know what the fields are (e.g. putting "in (dd/mm/yy)" format in the question or using placeholder text in the inputs)
When it comes to years, using yy is much easier for users, but it depends what you are using it for. If it is for a medical form, it isn't impossible to have someone who was born in the 1920's who would fill out the form. So in a few years you may find your form very confusing when you have an apparent baby filling out a form requiring a hip replacement.
Before I write my view, must say it was great answer by @Dominik Oslizlo!
Ok, for the year format, I think it totally depends on the following:
So already there are chances of mixing up the date and month, year is better mentioned full (YYYY)
Conclusion:
To avoid ambiguity, follow the DDMMYYYY format. It supports the way we refer the year in our daily lives. The tendency is to say 20 17 or 2k17 or whatever, but its complete YYYY format.
So, support the way users think. Hence YYYY would always be clear!
1. In the device: Keep user in control. Respect local settings of date format. Whether the user has system-wide YYYY or YY, respect it.
2. Context of user account: if user can log into a platform (e.g. website), take format settings from his profile. As a default, you can set ISO format (YYYY-MM-DD) or get the format based on user's country (see Veeresh's answer). Initially use ISO format when country is unknown. Once you have determined the format, handle date display and date entry as described in point 1 above. So YYYY or YY comes from the setting.
3. Global use: if data are targetted to be handed over to other users (e.g. reports in text form), always use YYYY, especially ISO date form YYYY-MM-DD. This will leave no one in doubts.
YYYY-MM-DD. No exceptions.