Just finished reading Caroline Jarrett and Gerry Gaffney's Forms that Work and I noticed that while the publisher used a screen shot on the front cover with that date format the authors didn't actually tackle the issue of DD/MM/YYYY in the book ... which provoked discussion about it when we reviewed the book at UX bookclub earlier this week.

Has anyone tested the use of the DD/MM/YYYY format string to communicate to users how to enter a date in a single or even triple text field? Or have you found it's easier just to provide year and month drop down lists?

What about for credit card detail forms where the input format must match the card so you have to use numerical dates in MM/YY format?

What are some alternatives that allow quick date input with text fields and also ensure the correct order?

  • 1
    Who are your users? It would seem like this question depends very highly on what population you are talking about. Commented Mar 29, 2010 at 16:48

12 Answers 12


William Hudson investigated this issue last year. He conducted a survey of nearly 1,000 people, asking them simply how they would write a given date (‘the second of August this year’ was how it was phrased). They typed their answer into a free-format text field. Respondents were then invited to choose the closest ‘template’ date from a list of 32 – half of which were in day/month/year order and the other half month/day/year (‘other’ was the final option).

People used a wide variety of date formats. Participants who used month/day/year ordering had a slightly stronger preference for a purely numerical date with no leading zeros in the month or day (8/2/09) but the close second used the full month name (August 2 2009). These two categories accounted for 53% of that group.

  • 5
    Great study but I don't see how this answers the question about recognition of DD/MM/YYYY?
    – Pdxd
    Commented Aug 28, 2015 at 13:33
  • 2
    It should be noted the survey was on an US/UK audience. year/month/day is the most common by international standards.
    – unitario
    Commented Sep 17, 2017 at 6:30

Well - I know from experience that folk from the US often mistype "DD/MM/YYYY" since they're used to "MM/DD/YYYY". For a site that addressed UK & US audiences we found that we got a lower error rate with "YYYY/MM/DD" :-)

As for alternatives that allow quick text entry - you might want to look at the ways you can enter dates on nationalrail.co.uk, which has several options.

  • Interesting. YYYY/MM/DD is also the preferred format in Japan.
    – Marcus Coghlan
    Commented Mar 28, 2010 at 23:53
  • 12
    Logically, YYYY/MM/DD is the correct way of writing dates. As with standard numerics the left most number is the highest; Thousands, Hundreds, Tens, Units. I kind of wish we could all change and everyone write dates like this. But then that's just the pedant in me!
    – JonW
    Commented Mar 29, 2010 at 13:38
  • Nice example, Adrian. The refresh National Rail site is pretty accommodating in that respect.
    – Janel
    Commented May 27, 2010 at 10:46
  • How does this answer the question? Commented Feb 23, 2019 at 18:03

To require a user to enter information in a free form text field in a format that you have defined is not good at all.

I think a date picker (calendar), multiple select boxes (with Jan, Feb, etc - showing clearly which field is for what), or a highly intelligent free text form is much better. However, I think most people would have to stop and think, not being used to a system understanding things like "tomorrow", which would make a more clear UI like the 2 first I suggested better.

  • 1
    Although in general free form fields with an "input tip" such as mm/dd/yyyy seems to be the overall recommended way to do this. Commented Sep 28, 2012 at 19:07
  • @JeroenEijkhof: because they work, especially when accompanied with date picker.
    – ya23
    Commented Jan 9, 2013 at 10:32
  • Typically, a format is required in situations where you are not at liberty to pick a more suitable UI. Think "name your file ... for fast processing" or "choose ... as an e-mail subject". Commented Feb 23, 2019 at 18:06

Just as a bit of background, there's an International Standard (ISO) for date format:



Its actually quite complex as to which country uses which format - and there's quite a nice Wikipedia guide (normal Wikipedia reservations applying...)


  • 2
    +1 Only format I'll ever find logical, but then again I'm from Sweden where slashes are weird ;) It also feels more logical for my thought process to figure out the year first, then the month and finally what day I'm after - so this seems entirely cultural/locale-dependant. Commented Jun 26, 2010 at 18:24
  • Further exploration of the W3 site reveals this comment "No ideal solution exists for this problem. Weigh the options and choose according to your preferences and your situation. If there is likely to be any ambiguity on the part of the user, it is usually best to use explicit month names and 4-digit years for Gregorian dates, or at least indicate on the page how to read the dates. Dates can be reformatted using dynamic techniques to match the linguistic context of the page." see w3.org/International/questions/qa-date-format
    – Nathan-W
    Commented Jun 26, 2010 at 22:40
  • How does this answer the question? Commented Feb 24, 2019 at 9:59

Whether users understand the DD/MM/YYYY prompt will depend on the audience of course. For people who spend time on other sites, or using applications in general, I think it's become pretty well known in most communities.

I like to support free-form entry with the system being intelligent enough to figure out what you mean. So Google Calendar understands "tomorrow" and parses accordingly, and treats 10/3 as 10th March (although of course this is locale-dependent).

For credit card expiry, the preferred format has to be anything except the one that forces you to choose the month by name (as this forces the user to "translate" from the numeric month printed on the card to the calendar month)!

  • You're right, the smart date feature on things like Todoist, Google Calendar and RTM have set an expectation for me. I'm pretty disappointed when I come across websites that DON'T support "today" or "next tuesday" etc.
    – Nathanael Boehm
    Commented Mar 27, 2010 at 1:32
  • 1
    The problem I have with free-form entry for dates is along the lines of what Adrian mentions in his answer - the US typically does MM/DD/YYYY and other countries do DD/MM/YYYY - free-form entry makes it impossible to determine if 1/2/2010 is January 2nd or February 1st.
    – Charles Boyung
    Commented Mar 29, 2010 at 13:13
  • @CharlesBoyung: But the question is precisely about the notation to clarify the expected ordering. Commented Feb 24, 2019 at 10:00

Some people may not understand "dd/mm/yyyy". To be clear, use plain English (day/month/year) and include an unambiguous example like 30/4/2010. Here's an example.

Date |________| day/month/year - for example 30/5/2010

This is the standard German date format. However, in German I would expect the localized string "TT/MM/JJJJ" :)

  • 2
    Not to be picky but… the standard over here is TT.MM.JJJJ – no slashes ;-)
    – Sascha Brossmann
    Commented Mar 30, 2010 at 3:12
  • Oh, dear me, you're right :)
    – Brian
    Commented Mar 30, 2010 at 14:02

For Europeans, DD/MM/YYYY probably works fine, although I'd add an example date. So it would something look like this (not sure if the formatting comes out):

[..] [..] [....]

DD / MM / YYYY (e.g. 25 / 05 / 2010)

(As you can see, one tricky thing is whether the leading "0" for the first 9 months is required or not)

Using a date-picker only works for nearby dates (either nearby the current date, or another know date). So they work great for appointments in the coming month, but not for birthdays or other random dates.

For credit card expiry dates, I'd use two drop-downs for months (1-12) and year (current year + next 5?).


Never had a real problem with DD/MM/YYYY - for Australian or New Zealand audiences. Most people seem to get what it means.

Did come across a functional spec though where the client wanted DD/MM/CCYY.

That got a red flag and a flat out "No" from me. :)

  • Did they give a reason for wanting it that format? It seems VERY odd!
    – Toby
    Commented Jun 6, 2010 at 20:01
  • 2
    It's does make some technical sense - CC for century (e.g. 21st), YY for the year. It's just über confusing.
    – Matt
    Commented Aug 31, 2012 at 19:59

DD/MM/YYYY means of course "Dam* You" - perhaps in the user's mind ;-)

Serious though, over the years developing applications that will receive dates - if typed manually they always become a problem, no matter what you do. There are just too many ways not just to think of dates, but also to type them. The format varies from country to country and so forth.

IMO date fields need to be child proof by offering drop downs - one for year, one for month and one for day - or a calendar to select the date from the grid.

Never ever let any user type a date manually!

  • 2
    Strongly disagree with "Never ever let any user type a date manually". Power users would find this limitation quite annoying. Imho ideal way is to offer a user an intelligent textbox with a format (e.g. dd/mm/yyyy) and a date picker. Power users would go for a textbox, others would use date picker, everybody's happy.
    – ya23
    Commented Jan 9, 2013 at 10:30
  • 1
    Your're right @ya23, I'm too generic in the last statement - though, I worded it in hope that the exaggeration came through :) It eventually boils down to: who is your audience. But working a lot with power users where main task is to enter dates for hundreds of reports daily (time report sheets), the amount of errors is noticeable - even then. There are techniques to "fix" these, but to specific for being a general solution - so, weighting audience and frequency etc. are important planning factors.
    – epistemex
    Commented Jan 9, 2013 at 11:49
  • There's a validation challenge when you setup dropdowns here. Would you restrict the day field depending on the Month? Would you display Leap Year based on Year validation? It becomes super awkward.
    – Pdxd
    Commented Aug 28, 2015 at 13:37

Swopping position of the Month and Day inputs seems to be the most problematic.

It depends on where the majority of your users are coming from. In the US, it's strictly MM/DD/YYYY, an opposite of most other countries, and most of these users will enter or select the Day followed by Month. It's a always pain when trying to figure out if it's the 7th of March or 3rd of July, just like switching from driving on the left to driving on the right. If you are not separating users by location, DD/MM/YYYY (lowest to largest value) and allowing only 1 to 12 in the Month input should work. Except for 7/3 !

  • How does this answer the question? The question is not about any ordering in particular, but about whether users will understand a pattern string and apply the ordering indicated by it, whichever that is. Commented Feb 23, 2019 at 23:17

Consider explicit date formats:

#yyyy0MMdd 2018-001-06
#dd0MMyyyy 06.001.2018
#0MMddyyyy 001/06/2018
  • How does this answer the question? Commented Feb 24, 2019 at 10:03