Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

In an application when you are showing a date to someone (and you don't know their preferred format), what date format should you use? USA or Rest-of-the-world?

For reference if anyone is not sure what these formats are, today's date would be:
USA = 10/07/2011 or October 7, 2011
Rest-of-the-world = 07/10/2011 or 7 October 2011

Assuming an equal probability that a user is from the USA or outside the USA, which format should I use?

Note, this question was largely triggered by the comments in another UX question.

share|improve this question
    
As worded this question can't have a good answer. Can you change the title and contents to something less contentious, like "what are advantages and disadvantages of different date formats"? –  Alex Feinman Oct 7 '11 at 14:15
    
I've never used neither of those nor would I ever be able to properly read those two... I guess I'm an alien ^^ –  Oskar Duveborn Oct 7 '11 at 14:20
    
@AlexFeinman: The title isn't the full question. If I wanted to ask about advantages and disadvantages I would have, but I want opinions on a specific situation. –  JohnGB Oct 7 '11 at 15:02
    
@AlexFeinman: I see your point about the title though. Ammended it to be less contentious –  JohnGB Oct 7 '11 at 15:23
1  
Also, the "rest of the world" doesn't only use DD/MM/YYYY so don't go assuming that everyone except Americans will recognize it either; YYYY-MM-DD is common in many countries like China and Canada –  Ben Brocka Oct 7 '11 at 15:25
show 3 more comments

9 Answers

up vote 15 down vote accepted

I've recently had to make a similar choice. And, yea, as a programmer, ISO 8601 is the best, but most humans do find it unintuitive, unfortunately.

I find that the problem isn't so bad for either side as long as you don't use pure numerical date formats. So this 12/10/2011 is certainly ambiguous, but Oct 12 2011 is not, and neither is 12 Oct 2011. So just stick to EEE months, if you can. There's no better.. there's just least surprising to the user.

share|improve this answer
2  
ISO 8601 is no less intuitive to an unbiased mind than the rest, it's that most users are used to seeing dates in a specific format, and it's often not ISO. Like the metric system, if we all used it from birth there wouldn't be any question =p –  Ben Brocka Oct 7 '11 at 15:10
2  
yea, but this isn't a hypothetical discussion about unbiased minds.. :) –  Assaf Lavie Oct 7 '11 at 19:30
    
+1 For noting that the key isn't in the relatve merits of the formats (which we could debate until the cows come home), but in making things unambiguous. –  Bevan Jan 28 at 0:52
add comment

The short format for one or the other should NOT be used, because the US standard MM/DD/YYYY is ambigious to the "rest of the world" standard DD/MM/YYYY. This means that if the user is not aware that the date format might be different than what he expects, it is not noticed. It is better to use October 7, 2011 or 7th October 2011 because although this might not confirm to the standard the user is used to, it is no doubt which date it actually is.

A good alternative is to use the global standard YYYY-MM-DD which is not ambigous.

If I see 10/07/2011, I immediately read 10th of July, 2011 without further thoughts unless the context indicates that this might be wrong. I might give it a second thought if the application has mainly US targeted audience.

To specifically answer the question in the title: "which is better?" the answer is: None is better! It is an insult to say otherwise.
If anything is better, it would be the global standard 2011-10-07.

share|improve this answer
1  
The question is given that you don't know their preferred format. Obviously if you know that, then you can use that. There are many situations where you don't know, such as text in a blog post. –  JohnGB Oct 7 '11 at 13:16
1  
@JohnGB: OK, I have removed my references to reading client locale settings. –  awe Oct 7 '11 at 13:38
add comment

You should use the long form and toss a coin to choose the format. Based on the information given there is no reason to favor one or the other.

share|improve this answer
add comment

If it's a 50% chance then neither is preferable, the only date format with an inherent superiority in any area is the ISO 8601 date format of YYYY-MM-DD H:i:s because it is computationally easy to sort in all cases by simple "higher or lower number" sorts and there is no ambiguity if you know the format. You can safely bet that almost no non-technical users are going to know the format by default unless their country happens to use it or a similar format.

The solution is to display the full name of the month in any written dates; "October 7th, 2011" can not be misinterpreted. When asking for a date input always state the format you're using near the field (e.g. MM-DD-YYYY).

To decide which format to actually pick, look at your domain. If it's a US domain (.us) or assumed to be a US domain (.com is often used as such for the big sites) some people may assume it's going to follow US conventions and in that case you may as well use US date format, as that's the best/only hint you're going to give. The same for .co.uk, ect. The only "best" here is what your users will most expect.

For related reasons the full 4 number year should always be used to help eliminate ambiguity, there's nothing worse than seeing 10/7/11 as a date format.

share|improve this answer
    
"there is no ambiguity if you know the format" - well, that's true of any format except for truly bad ones like MDYY [11111 is january 11th or november 1st?] What you mean to say, I think, is that since no other all-numeric* format in use begins with the year or uses four digits for anything but the year, then there's no ambiguity if you know that. *and the benefit of being all-numeric is really only relevant to the sorting thing. –  Random832 Oct 7 '11 at 16:38
add comment

The most important thing in this is of course what the users need and expect.

Things to do:

  1. provide unambiguous feedback about what the accepted result means (spell it out in text)
  2. accept the yyyy-mm-dd alongside others too
  3. provide a helpful hint about what format you could use so people don't have to find out through trial and error
  4. if possible, provide the user with a way to change the behavior if they want to.

Things not to do:

  1. solely use the browser locale as a way of determining format (not all users have control over that, especially on public computers, and not every user always uses the same format. I prefer English texts to have English settings for numeric and date, and European format for European measures. Intermingling is even more confusing)
  2. religiously block all options that are not iso-something compliant, because it comes at a cost of readability and usability. (The same for spelling it out in text, because it takes up screen estate. If it causes a table to scroll horizontally, it might not be the best option.) The goal is to prevent dates from being mixed - it is not about conforming everybody to iso-something. Assess the confusion and address it accordingly, but be as broad and providing as you can.
share|improve this answer
add comment

If possible, don't use either. Use a text abbreviation for the month ('Oct', 'Nov', etc.). Not much bulkier and less open to misreading. A lot more readable, and it tends to look nicer too, because you're not bombarding users with a stream of numbers and human-unfriendly separator symbols.

If your input form allows users to enter the date purely in digits, you can have it automatically parse the data and transform months into text the moment the user changes field focus. This gives instant and unambiguous feedback on the data received.

share|improve this answer
    
Just came across this but it deserves and up vote. I use a modified version of this scheme in that if the month has only 4 letters I use the whole name, otherwise the 3 letter abbreviation. "06 July 2013" –  obelia Jul 6 '13 at 17:01
add comment

It is always best to go with a format that will never be confused for another, in which case when you cannot know for sure which part of the world the user's date expectations will be, you should either convert to a named format (12 December 2011) or 2011-12-11. This avoids the question as to whether that is the 11th of December, or the 12th of January, as well as making it immediately obvious which numbers are the year.

If you are able to know locale is dominant, then you can consider supporting that date format, but in those cases you will need to make it clear that it's YYYY-MM-DD (or whatever variant you use), and it's good practice to do that no matter what.

share|improve this answer
add comment

Its an old question but I feel its worth adding my 2c.

I worked as a student for a big pharmaceuticals company that was based in both Europe and the US. All staff were trained to write the date in a specific way. I guess to ensure the there were no misunderstandings which would upset regulators but also to ensure dates couldn't be easily modified later. We also had to cross our zeros diagonally and ensure our 1's and 7's were easily distinguishable.

dd MMM yyyy - > 01 JAN 2014

The great thing with this format is that there is no way it can be misread and you don't need to know whether its European, US, ISO, etc to know exactly what was intended. In industries where mistakes pose a potential risk to patients in trials, getting it right is important. It's quite long-winded to write out by hand and you certainly tire of it when you're writing the date 50+ times a day, but the habit stuck and I still do it today having not worked in the industry for over 10 years.

share|improve this answer
add comment

Base it on where the user is from (use their system settings in a desktop app, and in a web app, base it on their ip address until they log in). Some countries don't even use the Gregorian calender (though it's almost universally understood).

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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