53

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?

  • 100
    In the year 2099, somebody is going to curse your name... – Stig Hemmer Apr 4 '17 at 8:31
  • 95
    Use neither. xkcd.com/1179 ...and a curse on your code if you ever use YYYY/DD/MM - that is an abomination. – Criggie Apr 4 '17 at 10:24
  • 106
    I did not expect such a question just 17 years after Y2K. – Dubu Apr 4 '17 at 10:35
  • 69
    en.wikipedia.org/wiki/ISO_8601 "an unambiguous and well-defined method of representing dates and times": YYYY-MM-DD . For example, September 27, 2012 is represented as 2012-09-27. No slashes. with time: YYYY-MM-DDThh:mm:ss ( or YYYY-MM-DDThhmmss for filenames), even including milliseconds if needed: .mmm . The "T" separator really helps taking out every ambiguities, and is easy to parse as well. iso8601 is a good thing, and should be used EVERYWHERE ! (I have log-search scripts that needs to "guess" amongst 12 date formats :'( ) – Olivier Dulac Apr 4 '17 at 14:48
  • 17
    There is no situation when one should use anything but ISO 8601: YYYY-MM-DD. No exceptions. – sds Apr 6 '17 at 16:28

15 Answers 15

84

There is no universally good answer to this question, but there are definitely two pros of YYYY:

  • by showing the two leading numbers you can easily tell e.g. 1911 from 2011,
  • you know exactly where the year is in cases when the year is from the range XX01-XX12.

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:

  • ▓▓-▓▓-▓▓▓▓
  • ▓▓/▓▓/▓▓▓▓
  • ▓▓▓▓/▓▓/▓▓
  • ▓▓▓▓-▓▓-▓▓
  • ▓▓▓▓-▓▓
  • ▓▓-▓▓▓▓

The day vs month problem: gradual versus cultural approach

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.

Professional usage

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.

"Now" context anchor

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

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.

Combining into one text string and sorting

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:

  • it is good to have a full year, because at least the photos from 2000 will be after those from 1999,
  • it is good to use the gradual order, progressing from higher to lower unit.

Wrap-up:

  • 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.

EDIT:

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.

  • 33
    Relevant link: xkcd.com/1179 – Prinsig Apr 4 '17 at 10:00
  • 102
    Why no mention of the ISO standard? YYYY-MM-DD. Surely the more people aware of the standard and the more people get used to seeing it, the better the standard and the lower the confusion. – thosphor Apr 4 '17 at 12:20
  • 30
    iso.org/iso-8601-date-and-time-format.html "ISO 8601 tackles this uncertainty by setting out an internationally agreed way to represent dates: YYYY-MM-DD . For example, September 27, 2012 is represented as 2012-09-27." . No slashes. YYYY-MM-DDThh:mm:ss ( or YYYY-MM-DDThhmmss for filenames), even including milliseconds if needed: .mmm . Get used to the "T" separator: it really helps taking out every ambiguities, and is easy to parse as well. iso8601 is a good thing, and should be used EVERYWHERE :) (I have log-search scripts that needs to "guess" amongst 12 date formats :'( ) – Olivier Dulac Apr 4 '17 at 14:39
  • 62
    -1 for "There is no universally good answer to this question" ISO-8601 exists. It is the "universally good answer to this question". Period. – Shane Apr 4 '17 at 18:53
  • 15
    @Sulthan "date should be formatted according to user language settings". The problem with this is that, more often than not, the user doesn't know if the date has been formatted according to their language settings. If a British person visits an American website and sees 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. – user31143 Apr 6 '17 at 8:44
64

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!

  • 9
    +10,000 if I could. This is a solved problem and there need be no more discussion or wishy-washiness. – thunderblaster Apr 5 '17 at 13:13
  • 4
    Standard published almost 20 years ago that settles this issue. We are still arguing over it.... Mandatory xkcd link – xDaizu Apr 5 '17 at 14:20
  • 7
    "Objectively braindead" is not only unnecessary, but also insulting and incorrect. MM/DD/YY is common because it is how dates are spoken where that format is used. September 7th, 99 = 09/07/99. It's objective and correct, just with a different goal. – DCShannon Apr 6 '17 at 0:27
  • 11
    "I have never once seen a program or process fail due to the choice of YYYY-MM-DD ISO 8601 Standard Date Formatting." +1 – user31143 Apr 6 '17 at 8:45
  • 6
    @ChrisSchneider Humans can parse MM/DD/YY just fine based on context. I have no idea how you can say that. Not counting of course my personal experience (which by the way is the same of all the other non-North-Americans/Greenlanders etc. with whom I ever discussed this) of having to guess the meaning of those potentially American dates every time the day is <= 12, you have several comments right in this page describing difficulties in doing exactly that. Unless by "based on context" you mean "based on knowing in which format those dates are". – SantiBailors Apr 6 '17 at 16:11
17

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.

  • 5
    @Vincent The confusiobn about MM and DD is avoidable only if you place full year first, like YYYY-MM-DD. – Eugene Ryabtsev Apr 4 '17 at 8:39
  • 15
    You picked one of the few examples where it does not matter; ignoring the uncertainty about the century, this is always Nov 11 2011, no matter how it is paresed ;) – Yogu Apr 4 '17 at 8:58
  • 4
    @Yogu: The point of this answer is not that the YYYY notation helps readers to disambiguate the date. This answer shows that the YYYY notation helps readers to realize quickly that they are dealing with dates in the first place. – Schmuddi Apr 4 '17 at 11:47
  • 3
    this! Just a few days ago I read a article somewhere dated from (something like) 11/05/15. I wonder when it was written... :-) 2011? 2015? May? November?... – user17696 Apr 5 '17 at 0:04
  • 3
    @DavidRicherby I make software for warehouses, and I have at least six clients who use the 2-digit / 2-digit / 2-digit nomenclature for indexing their inventory. Because we ran into the exact same problem, we switched to the DD-Mon-YY format— 04 Oct 17. This is simply one example, I'm sure there are many others. – Sujan Sundareswaran Apr 6 '17 at 1:11
11

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!

  • 2
    Ironically, your piece of text "dd Mon yyyy" is ambiguous because I first interpreted "Mon" as "Monday", not "Month" – Nayuki Apr 5 '17 at 3:47
  • 3
    I'm rather afraid that some of my old code might break sometime in 2036 ... – Hagen von Eitzen Apr 5 '17 at 4:55
  • 7
    YYYY-MM-DD doesn't baffle anyone. It has a 100% success rate in decoding. The worst that can be said is that it's unfamiliar to the general public, but it's intuitive. DD-MM-YYYY is not intuitive, and MM-DD-YYYY is even counter-intuitive. – MSalters Apr 5 '17 at 9:31
  • 1
    @HagenvonEitzen, you know, I'm a bit surprised to have had to scroll this far down for someone to mention this - Y2K was basically a scam for consultants to make quick money - 32-bit UNIX timestamps are everywhere. Hopefully won't be in 2 decades, but still. – zelanix Apr 5 '17 at 9:43
  • 6
    "Y2K was basically a scam for consultants to make quick money" No, Y2K was an actual problem that didn't cause many issues because we fixed it in time. – David Richerby Apr 5 '17 at 18:31
10

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:

"asked Jan 6 '09"

enter image description here


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.

Truncated representations

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.


From MS Window 10:

The YY options are completely valid

enter image description here

  • 20
    +1 For Iso Format. Come on ! Just use 2011-10-09, the standard is set since 1988 ! xkcd.com/1179 – Pierre.Sassoulas Apr 4 '17 at 10:05
  • 3
    @Pierre.Sassoulas They also had YY-MM-DD and YYMMDD but this provision was removed in ISO 8601:2004. – DPS Apr 4 '17 at 10:09
  • 11
    If I'm not dealing with century old events, but say, two decades of yearly reports, that I want to process in order, I order by date and get: 01, 02,... 16, 17, 97, 98, 99 Well, there is an aparent jump, and it isn't in date order... Use the full year notation, and use the ISO standard where possible – Baldrickk Apr 4 '17 at 15:14
  • 2
    @Baldrickk This is actually a great point IMO and I'm surprised no one else talked about it really. – JMac Apr 4 '17 at 16:50
  • 3
    "the YY or YYYY remains the same for entire world" It certainly doesn't. e.g. en.wikipedia.org/wiki/Islamic_calendar – Lightness Races in Orbit Apr 4 '17 at 18:48
9

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

  • it is not ambiguous in the given context
  • it is always stored as a 4-digit value

To illustrate 'given context':

  • a flight date on a booking site works well with a 2-digits year, because the user will never be able to book a flight date that is over 100 years in the future
  • a birthday date will hardly ever work well with a 2-digit-year, because at least some people get older than 100 years
4

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.

4

Advantages of YY:

  • Saves 2 letters of space
  • Saves 0.2 seconds of time when typing the date.

Disadvantages of YY

  • Requires you to use different date formats in the same product (you must use YYYY in some cases, at some point)
  • Adds ambiguity (which century?)
  • Adds ambiguity (which one is the year and which one the month?)
  • Adds ambiguity (which one is the year and which one the day?)
  • Takes 0.2 seconds longer to read (because of ambiguity)
  • Increases risk of user error (worse input verification, and because of ambiguity)
  • Increases risk of programming errors (usually involving sorting)

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.

  • 1
    It's a good way to look at it, but I suggest doing the PRO and CON of YYYY too. The disadvantages of YY are not necessarily a 1:1 match with the advantages of YYYY. – JonW Apr 7 '17 at 14:49
3

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.)

  • Love me some fun anecdotes in answers! Y2K was fun indeed! – Dirk v B Apr 9 '17 at 23:29
2

Most of the people uses DD/MM/YYYY format. Based on region/country format is varying. Date format by country

  • 1
    Oh, thanks, I didn't know they actually kept a record of which format each country uses frequently. Thanks for sharing. – Vincent Apr 4 '17 at 7:15
  • 10
    iso.org/iso-8601-date-and-time-format.html "ISO 8601 tackles this uncertainty by setting out an internationally agreed way to represent dates: YYYY-MM-DD . For example, September 27, 2012 is represented as 2012-09-27." . No slashes. with time: YYYY-MM-DDThh:mm:ss ( or YYYY-MM-DDThhmmss for filenames), even including milliseconds if needed: .mmm . The "T" separator really helps taking out every ambiguities, and is easy to parse as well. iso8601 is a good thing, and should be used EVERYWHERE :) (I have log-search scripts that needs to "guess" amongst 12 date formats :'( ) – Olivier Dulac Apr 4 '17 at 14:44
  • 1
    @Criggie it's sensible to target your usage to the usage of the majority of your users. – Tim Apr 4 '17 at 14:53
  • 3
    With "most", you refer to the order (DMY), but not the separator, right? If you say most use "DD/MM/YYYY", it suggests that most would use the slash to separate, but the linked page doesn’t seem to claim this. – unor Apr 5 '17 at 0:59
  • 2
    -1 a relevant fact and useful link but not a satisfactory answer to the question. – user31143 Apr 6 '17 at 8:48
2

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.

  • A proposal to extent ISO-8601 solves this: For any five-digit year, prefix with "A", six-digit with "B", etc: 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. – Monty Harder Apr 5 '17 at 17:46
  • This doesn't really answer the question about whether it should be 2 or 4 digits long, just that you do it as YY for convenience. Can you elaborate and explain whether YY or YYYY is more beneficial, and why? – JonW Apr 7 '17 at 14:51
1

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:

  • Date of birth: 1999 comes before 2000, but 99 would sort after 00, so for a DOB in something like a drop-down, a 4-digit year makes sense (displaying 2 digits but sorting by 4 is doable, but can be confusing to the user).
  • Calendar app: Google calendar's interface isn't ideal for this, but I can add events before the POSIX epoch -- so if I had diaries from the 60s I could digitise them into google (that would be a bad idea, besides I wan't born then). Alternatively I could probably use it to plan out a novel set in the 23rd century. If you're building something general-purpose, your users will come up with more uses for it than you ever could.

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.

1

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:

  • Audience (Their geographical region) - Users in Asian countries prefer saying the date first and then specify the month. It's opposite for the North America or western countries. For example, 9/11 is the American way of telling date whereas in India it's 26/11. Now, this is an interesting example as both the dates are associated with terrorist attacks. 9/11(11th Sept), the world knows about it and 26/11 (26th Nov) for the Mumbai attacks. The way it is referred is noticable. It reflects the culture.

So already there are chances of mixing up the date and month, year is better mentioned full (YYYY)

  • Purpose (If the purpose to ask date and year to establish an event happened recently or is it a date of birth) Imagine a case of birthdays. Is there any way one can ascertain that user was born in 19yy or 20yy if it's mentioned only yy format.

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!

  • 2
    Can you explain how the DDMMYYYY format follows alphabetical order? – Nayuki Apr 5 '17 at 3:46
  • 1
    @Nayuki "D" < "M" < "Y" – Mathieu Guindon Apr 5 '17 at 17:08
  • 3
    You say that, Americans and westerners in general prefer to put the month name before the day. This is not true. Americans do generally say, e.g., "April 5th", which matches the way they write dates in numbers. British English seems equally happy with "the 5th of April" and "April 5th"; French and German (as far as I'm aware) only say the equivalent of "5th April" and (though I admit this is getting sketchy) using Google to translate "April 5th" into just about any European langauge seems to give the equivalent of "5 April". – David Richerby Apr 5 '17 at 18:40
  • 3
    I cannot think of a more wrong / pointless criterion than following the alphabetical order of D, M, Y. I agree about the pros of DDMMYYYY that you mentioned but I would definitely avoid any reference to the alphabetical order. – SantiBailors Apr 7 '17 at 14:53
  • Yup agreed! Alphabetical order basis doesn't make sense. – pzv Apr 11 '17 at 10:24
0

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.

  • 9
    11th Oct of 2009? – Oleg V. Volkov Apr 4 '17 at 15:09
  • 2
    But using words means you have internationalization problems. – David Richerby Apr 5 '17 at 18:32
  • 2
    It solves the problem for "all users" who speak English. – user31143 Apr 6 '17 at 9:01
  • 1
    @dan1111 I'd make the assumption that the site would translate based on the user's language (or by allowing the user to change the site's language) - if aiming for international audiences. E.g. default may be 09/Feb/11, but in French see 09/Fev/11 – jordsta95 Apr 7 '17 at 8:40
  • 1
    Most of this answer is referring to date format. Only the last paragraph actually answers the question that was asked - should year be 2 or 4 digits. – JonW Apr 7 '17 at 14:48
-1

Distinguish between display for personal use and form for interchange of data between users.

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.

  • Display all dates according to local settings in the machine.
  • Expect entry of all dates according to local settings in the machine PLUS additionally allow ISO format for date entry (YYYY-MM-DD).

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.

  • The question is not about date format. It is about whether the year should be 2, or 4 digits long. – JonW Apr 7 '17 at 14:45
  • @JonW – thank you for pointing to that. I modified the answer accordingly to make its point more clear. The YYYY vs. YY is generally out of debate on systems where system-wide format settings already exist. (Ignoring them and introducing independent display form is a bad practice.) Where this is not settable, YYYY should be preferred (as part of YYYY-MM-DD, not other order) to avoid any doubts. – miroxlav Apr 8 '17 at 20:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.