Should date validation allow "091011"?

Question

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 /)?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

or

• User enters 091011
• System displays 10 September 2011
• User knows the computer didn't understand and corrects the field.

Answer 5

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:

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:

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 icon to show that they can also pick the date from a calender.

Answer 6

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

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.

Answer 7

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

Answer 8

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

^{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.

^{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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.