10

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.

Improve this question
10
  • 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, 2011 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, 2011 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, 2011 at 15:02
  • 2
    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, 2011 at 15:25
  • 1
    Nitpicking: ISO-8601 standard date format is YYYY-MM-DD (with hyphen), not YYYY/MM/DD. :-)
    – Pablo H
    Jul 15, 2021 at 15:24

9 Answers 9

Reset to default
18

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.

Improve this answer
4
  • 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, 2011 at 15:10
  • 3
    yea, but this isn't a hypothetical discussion about unbiased minds.. :)
    – Assaf Lavie
    Oct 7, 2011 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, 2014 at 0:52
  • 1
    UBER's CEO had landed to Indian airport with invalid Visa because of the date format confusion ibtimes.co.in/…
    – Jitendra Vyas
    Dec 18, 2016 at 15:10
5

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.

Improve this answer
1
  • "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, 2011 at 16:38
5

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.

Improve this answer
3
  • 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, 2011 at 13:16
  • 1
    @JohnGB: OK, I have removed my references to reading client locale settings.
    – awe
    Oct 7, 2011 at 13:38
  • @awe the "rest of the world" standard is DD/MM/YYYY or YYYY/MM/DD. 1.6 billion of people use the latter format so you can't ignore it
    – Andrew
    Apr 21, 2016 at 11:22
4

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.

Improve this answer
3

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.

Improve this answer
1
  • 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, 2013 at 17:01
1

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.
Improve this answer
1

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

Improve this answer
0

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.

Improve this answer
0

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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