Should I allow users to input the MMDDYY or MMDDYYYY format for a date?

That is, should any date validation logic not trigger a validation error if the user just wants to put in the numbers without any separation symbols (., - or /)?

  • 2
    Know your audience. In general, a date picker removes all ambiguity, but if it is an internal data entry application, for instance, where the user will be manually adding a date in a known format, then simply inputing a string of numbers will be much faster for their workflow. Commented Oct 7, 2011 at 12:58
  • 1
    Check out the kinds of dates that Outlook lets you type in - it's pretty neat. blogs.technet.com/b/kclemson/archive/2003/11/07/53899.aspx It's also a very good example of the Robustness principle I mentioned in my answer.
    – Bevan
    Commented Oct 7, 2011 at 21:23
  • 8
    And what about DDMMYY or DDMMYYYY? Commented Oct 7, 2011 at 22:18
  • 1
    +1 to @hippietrail; 091011 would be the 9th of October 2011 to me
    – feeela
    Commented Jul 2, 2013 at 12:59
  • And 2009 October 11th to me
    – Pentium100
    Commented Aug 21, 2015 at 5:38

12 Answers 12


The usual caveat of "it depends" applies -- if the users are typing in dates which they are reading off from somewhere else, and that reference material is formatted as MMDDYY or MMDDYYYY then, yes, let them simply transcribe it.

Also, if the users are data entry process workers (eg. in a call centre) and not casual website visitors, then let them perform data entry in a keystroke efficient manner.

  • 2
    +1 for efficiency in data entry. In applications where there's frequent data entry, such as creating multiple invoices. Having regional variations help when you know the date preference of your users i.e. rest of world or US. There's nothing that frustrates non-US users more than forcing them to conform to a dd/mm/yy format -- and let's not even mention the requirement to put in the separators. It's important to tailor the form, application, etc... so that it speaks their language, including regional nuances.
    – Janel
    Commented Oct 7, 2011 at 9:57

The moment a date is ambiguous you should not convert it to what you think it is.

For example, in most of the world date formats are DDMMYYYY or YYYYMMDD, but for some (silly) reason the US uses MMDDYYYY. You know that this is likely to be a confusion, so don't convert a date that is ambiguous.

If the date is critical, consider using a date picker rather than using numbers.

Another way of handling this is to convert the date once entered into words. Like 9th October 2011. That way if I meant 10 September 2011 I will be more likely to notice the change.

  • If you want your user to be able to enter an unformatted date, I would include some specification of the expected format. This could be as simple as a "MMDD(YY)YY" label or cue banner, or an edit mask that will insert the formatting as the numbers are entered. That way, the user is either warned what their input will be, or they will see it being turned into a formatted date and can say on the spot "no, that's not what I wanted" and correct it.
    – KeithS
    Commented Oct 6, 2011 at 20:54
  • It makes sense to me because that's the order in which we say the date. January 1st 2012. 01 01 2012. But i know in other parts of the world they say something like 10 May 2011. Which I don't find intuitive. Commented Oct 7, 2011 at 4:24
  • 3
    It makes sense to the rest of us because its the same order that everything else works in. Time is the same reversed, 15:02:11 is Three-Twenty pm and 11 seconds. While thats the reverse of the data format, it seems weird to swap any of the two around. Thats how it seems un-intuative to us non-US'ers
    – Tomas
    Commented Oct 7, 2011 at 6:26
  • 12
    "Fifteenth of May, 2012". Of course, the only logical order is YYYYMMDD - just like HHMMSS, the longest unit come first. It's also entirely unambiguous; nobody misreads 2012-06-05.
    – MSalters
    Commented Oct 7, 2011 at 7:46
  • 2
    But if you show them 2011-10-07? The slashes sure don't look like dashes ^^ Not that I disagree on your conclusion. Commented Oct 7, 2011 at 14:24

Good answers above. Just one more tip, though:

Consider having your application parse and re-write the date the moment the field loses focus. If the user types 091011, transform it into "9 October 2011" (or "10 September 2011" for US users) - your user will instantly see if his entry has been misinterpreted.

  • 4
    I'd rather see a seperate field for the text. Transformations on the input fields are a bit - meh
    – Barfieldmv
    Commented Oct 7, 2011 at 7:17
  • 1
    @Jimmy: Consider that which answers were above yours when you wrote it won't necessarily stay above after a bit of voting activity. Commented Oct 7, 2011 at 22:21
  • +1, I believe this is the design a company like Apple would take. It will auto correct it into the appropriate format, allowing the user to easily fix any mistakes without having to deal with the short hand notation again. Commented Oct 15, 2011 at 11:05

The problem is that the date is never ambiguous to the user - they always know what they mean.

  • User enters 091011
  • System displays 09/10/11
  • User assumes the computer understood correctly.

Simply accepting 091011 and leaving it that way doesn't resolve this because the user doesn't get to see if you have a difference of interpretation.

Key Principle

Be liberal in what you accept, precise in what you supply.

(aka The Robustness Principle - thanks to Patrick McElhaney, below, for the reference.)

Accept the user typing in 091011 by all means, but convert and display it in an unambiguous format so that any misinterpretations can be seen.

  • User enters 091011
  • System displays 09 October 2011
  • User knows the computer understood correctly.


  • User enters 091011
  • System displays 10 September 2011
  • User knows the computer didn't understand and corrects the field.
  • 1
    We're doing just that in a web-app. We're also dynamically reflecting other potentially ambiguous data entry. For example, we ask the customer to enter a SWIFT code (eg. BOFSGB2S) and we then display our interpretation of it (Bank of Scotland, Glasgow branch). There's probably a name for that design pattern.
    – Erics
    Commented Oct 7, 2011 at 3:33
  • +1 Love the key principle: 'Be liberal in what you accept, precise in what you supply' It's sound advice to avoid ambiguity.
    – Janel
    Commented Oct 7, 2011 at 10:00
  • The principle, "Be liberal in what you accept, and conservative in what you send," is a quote from Jon Postel and known as the Robustness Principle. Commented Oct 7, 2011 at 14:29
  • 1
    "Be liberal in what you accept" can actually backfire. Incorrect HTML markup is ambiguous; if browsers had historically rejected and refused to display it, coders would have learned to do it right. Instead they took a best guess how how to display it, and each one guessed differently. Then we got lots of bad legacy markup for which browsers had to maintain backwards compatability. Commented Oct 7, 2011 at 17:55
  • Thanks @PatrickMcElhaney for the reference, added that in place.
    – Bevan
    Commented Oct 7, 2011 at 21:09

Date validation has always been a problem due to American MM/DD/YYYY vs small Endian DD/MM/YYYY vs ISO YYYY-MM-DD, I can't imagine asking or allowing users to enter raw numbers with no separators and hoping it works well. In my subjective experience I must also say I have no idea who on earth would enter a date in this format unless it was a date field such as this example from Quince which allow you to only enter the numbers, as the separators are already there:

enter image description here

A nice trick with this sort of field is you can make the fields skip to the next once one of the numbers has been entered, so you can type 121212 and it will automatically be seen (and entered) as 12/12/2012, and you can style it so that the slashes appear to be part of the field so they're not so visually ugly. If you want to let users enter the raw numbers this is the only way to go. Note: Actually making them separate fields is very unfriendly, I wasn't suggesting that. The cursor should be able to move between day/month/year just by pressing the left and right arrow keys. It should be a single "field" and the cursor simply skips over the / separators.

You might want to consider other date entry methods as well, all of the best ones guide the user along to help them from typing invalid dates, rather than assuming they're entering a valid date (if users always entered the right data one time we wouldn't need validation, now would we?). Live UX has a good rundown of many of the options, you'll probably want to note the following:

If the data being captured could exist in multiple formats, a best practice is to provide a flexible input field that will allow a user to enter the data in any way format they wish. A script can then be used to validate and transform the entry into the appropriate format required within the system.

If you're going to let them enter 121212 as a date you must transform it to 12/12/2012 (Or whatever the standard separator is for your area/users) and indicate (MM/DD/YY) somewhere on the field. Quince also has a couple good articles about picking dates, the ideal way to remove ambiguity is the date picker: enter image description here

But these can be visual clutter and are a lot slower than typing the date if (if!) the user knows the exact date they're entering. To solve both problems you can give the plain text entry field for the date with a little enter image description here icon to show that they can also pick the date from a calender.

  • 1
    As a side note, I always consider a sample date as 12/12/12 because without context any of those fields could be day, month or year. You want to make sure the date 12/12/12 as entered shows clearly as...whatever the heck date you want that to be.
    – Ben Brocka
    Commented Oct 6, 2011 at 14:07
  • 6
    "fields skip to the next" this behavior is incredibly annoying as usually implemented - if you make a typo in the last digit of one field, it's often very difficult to correct it.
    – Random832
    Commented Oct 6, 2011 at 16:15
  • @Random832 The way I've seen it (best) implemented lets you treat them all as a single text field so you can cursor back and forth between any field (they're not separate fields you need to "tab" out of), the cursor simply skips over the / or - separators as a "field" is filled. Can't think of an example but I know I've seen it in JAvascript.
    – Ben Brocka
    Commented Oct 6, 2011 at 19:03
  • 2
    The problem is it's not often implemented properly. Whenever I've seen it, if it supports cursor movement between subfields at all, the field you move into will have all text selected - and moving the cursor within a subfield that is full (for example, to deselect) will make it advance to the next field no matter what your position within it is [since they just handled it as "keydown: length check then advance"] I've seen must have been hundreds of date/credit card/product key fields like this, and I can't remember any of them getting it right.
    – Random832
    Commented Oct 6, 2011 at 19:10
  • 2
    @Random832 the "Masked Input" plugin for jQuery got things right! Just for reference. It uses a single text box with the "mask" automatically inserted, but doesn't hinder user input. Commented Oct 6, 2011 at 23:10

As long as the date isn't ambiguous, it should be allowed. If you indicate that your expected format is MM/DD/YYYY and they enter 091011, consider auto-correcting it when they lose focus to the textbox. So it'd become 9/10/2011.

Of course the important thing here is that you should indicate your expected format. I was responsible for a site which saw thousands of online insurance applications and we used the MM/DD/YYYY format like so...
enter image description here

But then, we only serviced businesses based in the US, where MM/DD/YYYY is the defacto standard. If your site reaches a more global audience you might want to consider another approach, or even a date picker.

  • 3
    Additionally, making that MM/DD/YYYY field changeable would allow a user to write the date the way they want to, and you could store their choice in a cookie so that it stays when they come back to a similar field later.
    – zzzzBov
    Commented Oct 6, 2011 at 15:50

You can always allow ISO format, because YYYYMMDD cannot be confused with either of the other common standards, MM/DD/YYYY or DD/MM/YYYY, because these will place an (invalid) 20 in the month field.

However, 8-digit non-ISO and 6-digit anything can be ambiguous (at least until 2032), so relying upon that alone is inadequate. You can ask for a confirmation, allow text descriptions for the months (e.g. looked up in a suffix tree, so jun jul s se sep sept would all return a valid and unambiguous month), use a graphical pop-up, have them select which date format they're using (if a few errors are not dire, having it stated or pre-selected should be enough, but error rates will be lower if you force the user to choose); or have them verify that the date is correct.

Having separators does not help since MM/DD/YY has exactly as much ambiguity as MMDDYY, and we can already tell YYYY/MM/DD apart from the other two.

Personally, I've always chosen ISO format, but then my users are fairly technically savvy. If you're after maximal reliability for non-technical users, it's hard to beat the bulletproofness of clicking on the date in a calendar. (Typing is error-prone for non-touch-typists because they often don't look back up at what they've typed to make sure they didn't make a mistake.)

  • 1
    More specifically, this is ISO 8601 format. The standard allows several variants. For human-readability and simplicity of parsing, RFC 3339 requires YYYY-MM-DD. Commented Oct 6, 2011 at 23:14

The best is to have one field with the date separators '/' displayed in it as a greyed out input mask.

mockup with no data entry

download bmml source – Wireframes created with Balsamiq Mockups

When the user enters the date without the separators, the numbers will be formatted around the separators. This way you support the correct date display without forcing the user to press an extra tab key or have the automatic tabbing getting in the way of flow of input.

user has typed "11"

download bmml source

For those users that are used to putting the ' /' delimiter in, entering the delimiter will format the entry accordingly. This would be useful for faster entry of dates that have only single digit days and months (eg 1/1 in three strokes instead of 01/01 in 5).

And finally, the mask can be further modified to display the day / month order which disappears as the user enters each digit.

  • 1
    Nice. The user's cursor would advance to the next sub-field naturally if they type two digits, or the user could manually advance by typing either a TAB or a "/" (or a "-" or a "." or a " " for that matter). Having the cursor advance past the separator inside the field would feel natural. Compare if you had 3 separate fields which auto-tab if you type 2 digits .. that behaviour always catches me by surprise.
    – Erics
    Commented Dec 2, 2012 at 14:15
  • 2
    @Erics: if you do support autotabbing you should also be careful to swallow tabs that happen immediately after the focus is moved programmatically. It's infuriating to type 11[tab]12[tab]2012 only to have the date entered as 11/[empty]/12.
    – Kit Grose
    Commented Dec 3, 2012 at 4:00
  • darn right @kit-grose .. it should eat any extraneous separators
    – Erics
    Commented Dec 4, 2012 at 5:57

Alan Cooper would argue that the date should be parsed; it's a matter of user experience.

  • Is it a birthday? Then it's obvious what the date is: October 11, 2009
  • Is it the web-surfer's credit card expiration date? September 10, 2011

If a human can infer the date from the context: the computer should do the same thing. There's no reason the user experience needs to suffer because programming is hard.

Even if the date is ambiguous enough that a human decide: who cares - save it anyway. If it's that important then the user can fix it later.

Certainly you can hint to the user "Umm, sorry, i'm not sure what date that is". The user can then decide what to do. If the user doesn't care - then don't care. If the user cares they can change it into a form that the "dumb" computer can understand.

But don't "stop the proceedings with idiocy".

From About Face by Alan Cooper, page 398

If the data is bounded - but not to bounded - the program must let the user enter the data, only to reject it afterwards. Although there are some mitigating steps, there really is no good way to solve this problem. Unless...

There is one way to solve this problem: the program should just go ahead and accept whatever the user enters. In other words, eliminiate semi-bounded data. Either coerce the correct data with a bounded gizmo, or accept whatever the user gives you in an unbounded gizmo. Moust programmers reject this solution. They do not feel that their programs can accept, for example, "asdf;lkj" as input to a social security number field.


A fundamental improvement, based on the axiom that things behave differently should look differently, is to make validation gizmos visually distinct from unvalidated gizmos. I recommend using a different color and line style for the gizmo's border. A dashed line in blue instead of solid black would alert the user that something was up.

The main tool for validation gizmos is to provide rich status feedback to the user. Unfortunately, the edit gizmo as we know it today provides virtually no built-in support for feedback of any kind. The designer must specify such feedback mechanism in detail, or none will be provided.

  • How do you know it isn't 2011-10-09? Commented Oct 6, 2011 at 23:20
  • @Mechanicalsnail: i don't. But the user who typed it in does.
    – Ian Boyd
    Commented Oct 6, 2011 at 23:38
  • I don't get how you could assume 091011 becomes 11/10/09 (d/m/y).
    – Erics
    Commented Oct 6, 2011 at 23:56
  • 1
    The same way i would assume 09/11/32 represents October 7, 2011: the user was in Saudi Arabia which uses the Islamic calendar. The reason i read a date 091011 as ddmmyy (i.e. October 9, 2011) is because the user is in Canada (where we use dd/MM/yyyy). If the user was in the United States (where you use M/d/yyyy) it would be September 10, 2011.
    – Ian Boyd
    Commented Oct 7, 2011 at 13:07

I've come across this kind of thing before in my work. If you're talking about allowing a user to enter the date in a textbox (for example), and then converting what they've typed into a date, it's a good idea to provide a date picker, or split the date into separate fields for Day Month and Year (see various date of birth checks on M/R/18-rated movie or game sites).

If you can't provide a date picker or split up the date (e.g. due to requirements), then you need to provide the user with feedback on their date; either telling them the format you're expecting (DDMMYY vs MMDDYY) or automatically converting whatever they type into a different date format (such as YYYY-MM-DD, which is unambiguous) when your box loses focus. (Or both!)

For example, specify in a label that you expect MMDDYY. That way, if the user types 130103 (a potential UK standard date of 13th January 2003), you let them know immediately that you cannot convert it using the US standard you're expecting because there is no 13th month. However, this doesn't help the user if they type 010203, expecting it to be treated as a UK standard 1st February 2003, but actually getting it treated as US standard 2nd January 2003, which is why you should convert it on-the-fly so they can check it... Better to use a date picker though, if you can!

In one of the applications I've worked on, designed to be used in the UK, users were allowed to enter 010203. As soon as they tab out of the field, the value they entered was converted to 01/02/2003. However, if the user was entering 010203 to mean 02/01/2003 (US standard), this would, of course, be an invalid date and the user may never have noticed. We quickly adopted date pickers, although the legacy behaviour remained for old-time users.


Make sure they can't do it wrong

Do not try to guess what the user meant - make sure they know exactly what they're entering.

You can:

  • Use a datepicker
  • Use series of select-boxes for year, month and day (no JS required)

Yes, these are both slower than typing text, but they will get correct input.

Easing the pain of selects

Selects may seem heavy-handed, but consider:

  • Savvy users can learn to tab from field to field. In many browsers, focusing on a select input containing a list of the months and typing "Nov" will select November. Used this way, selects are as fast as free-form inputs, and "November" is completely unambiguous, unlike "11".
  • You may be able to ease the pain with sensible defaults. Obviously, if the user is entering their birthday, you can't guess that, but imagine they're using select boxes to choose a day to ship an order. In that case, you can default to the earliest possible day; most users will change one dropdown at most.

Just don't take ambiguous input. If you guess wrong, it will be your fault. You can't read minds - don't try.


I would enable users to enter the date in their desired format according to the preferences in the country/locale setting, or what they are used to in their working environment. Java can parse the dates for the correct storage and processing requirement, for example.

Where the dates must be stored in a particular way, you can use date masks or converters to convert the date entered into the required format: http://jdevadf.oracle.com/adf-richclient-demo/docs/tagdoc/af_convertDateTime.html. Java also allows a series of convenience patterns to be defined for date entry, even where the date could be ambiguous, but that can be problematic and is best avoided if your UX is intended for operation in a global context of use.

Allowing heads down workers, 10key keyboard users, or CRUD data workers to enter the date directly into the field by typing rather than by date picker and then handling any errors once submitted to the database enhances productivity rather than throwing errors that require the users to review and fix once they submit the entire page.

HTML5 offers some nice affordances for telling users upfront what a format should be: http://slides.html5rocks.com/#new-form-types.

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.