International Formats

A part of the problem is that designers are often faced with international visitors to their websites. Different geographical regions  have their own popular format. Please find an incomplete list of popular formats below.

ISO 8601 International Date Format

• 2008-12-31(ccyy-mm-dd)

The international date format is adopted by several countries. Many people around the globe have never used this notation however.

United States of America

• 12/31/2008 (mm/dd/yyyy)
  
• December 31, 2008
• 31 December 2008
• 31-Dec-2008
  

The month/day/year order is unique to the USA, Canada and the Phillipines.

United Kingdom

• 31/12/2008 (dd-mm-yyyy)
• December 31^st, 2008
• 31^st of December 2008
• 31 December 2008

Kingdom of the Netherlands

• 31-12-2008 (dd-mm-yyyy)
• 31-12-'08 (dd-mm-yy)
• 31 december 2008
  

Greater China

• 2006年01月29日

The international date notation is popular in China. Chinese characters are often used for the words for year, month and day.

Norway

• 31.12.2008 (dd.mm.yyyy)
• 31/12-2008 (dd/mm-yyyy) (used in handwriting, usually without the year attached)
  
• 31. desember 2008

Of all the different formats above, only one notation is used in nearly all of these countries: 31 December 2008.

The Aztec calendar was the calendar of the Aztec people of Pre-Columbian Mexico. It is one of the Mesoamerican calendars, sharing the basic structure of calendars from throughout ancient Mesoamerica. The Aztec calendar was the most precise calendar until the arrival of computers.

Input methods

I'll summarise the three most common methods:

The single field pattern

Many interaction designers are an advocate of the single field form. The valid argument for this is that users don't have to click or tab more than necessary and that the backend could filter out zero based notation, dashes, dots and so forth, in order to save it the right format. A user instruction is often placed next to the input field in order to make sure that users will always enter the month as either a number, or as a name.

Disadvantages:

• User has to read instruction
• User will copy dashes or other separation characters, even if not necessary for processing
• Date syntax doesn't read as natural language (as opposed to syntices that use a spelled out month name)
• I18n limitation: Different separation marks are used internationally
• I18n limitation: Different day vs month order is used internationally. User could easily overlook this in the instruction
• Limited form validation possibilities

Advantages:

• Few clicks or tabs
• Semi natural input
• Fast input for data entry
  

Conclusion

The single field method is a useful form when it's known that:

• All users will be from the same geographical region
• Server is capable of intelligent post processing
• Emphasis is on speed and ease of input, rather than on unambiguousness

The separate fields pattern

The separate fields method is probably one of the most common of date input methods that are out there. It gained popularity because maintainers of backend systems like the way the different values can go straight into the database as numbers their respective fields.

Validation is also much easier using this method than with the singe field method, because the limit on the amount of characters can easily be set in the HTML code and the minimum of characters and their value could easily be checked by either a JavaScript, or by the backend. E.G.: A number as high as 30, could never be a month and a three digit value could never be a year, nor day. International users would also not easily mix up day and month, as it is easy to label all the input fields individually. (If not necessary for accessibility reasons)

Disadvantages:

• User has to tab or click more, unless smart automated tabbing scripts are applied
• User could still enter the name of a month, rather than a number or the other way around, so validation is necessary for that, which is annoying for the user in the case of a mistake

Advantages:

• Less mistakes possible than with the single input method
• Less ambiguous
  

Conclusion

The separate fields method is particularly useful if the backend cannot do any intelligent post processing and/or when accuracy of input is of the highest importance.

The all drop down pattern

Another input method that I've seen users yell at during numerous user tests is the all drop down method. A dropdown is used for the day, the month as well as for the year. Selecting a day from a list of up to 31 items is simply tedious. Scrolling through the list is often required and year drop downs may be even longer.

Disadvantages:

• Tedious input method because of many mouse clicks and or button presses
• Much markup
• Non standardised order of years (running up or down, domain)
• Untouched forms are validated
  

Advantages:

• Totally unambiguous
• No backend intelligence required
  

Conclusion

Heaven forbid.

The Cornelis Hybrid

Observing all of the above, we might filter out the following key elements:

• Drop downs are more precise than free form input fields, yet tedious when they contain to many items
• Month and day fields should be distinguishable to prevent confusion because of different date order traditions
• Avoid user instruction
• Avoid too much dependency on backend post processing
  

Hence I'd like to pledge for the following method which works well under all conditions:

1. The day field is a free form input field as dates are usually written as numbers, not as text, so there could be no confusion about how to use this field. The maximum amount of characters should be set to 2 in the HTML code.
2. The month field is a dropdown. Because there are only 12 months in a year, the user doesn't has to scroll through endless lists of numbers. The fact that the month is written as text makes the syntax look natural for most people who use the Gregorian calendar, including Americans and Europeans. In fact, the syntax with a wider year field, a narrower day field and a text month notation looks so natural that no visible labels are required. This in contrast to the separate fields method.
3. The year field is a simple input field, so that any kind of year may be entered. If any kind of domain is required, an instruction and/or JavaScript real time correction could be applied. The maximum amount of characters in this field can be set to 4 in the HTML code and the minimum amount characters, which could be either 4 or 2 depending on the application, could be checked by the backend, but only if necessary. The width of the field will usually already be enough of a hint for the user to extract whether a 2 or 4 position year number is desired.

Even if the date and month were swapped out to accommodate for users of a specific region (such as the USA), then users from other countries would still not take the month for the date, as all the names of the months are already fully written out. What's left then is the day and the year field. The day field is significantly narrower than the year field, which makes it highly unlikely that the user would confuse those two by mistake.

For certain use cases where people use the month number as a reference — such as a credit card information form — you might want to consider to include the month number in between brackets behind the month name for ease of use.*

The advantages are clear:

• No drop downs are used for long lists
• Date and month order reads natural to all users
• User instruction or backend processing are not required in most cases
• Totally unambiguous

Tip: Even though no visible labels are required for this pattern, make sure the proper day, month and year labels are included always in the markup for accessibility reasons. The labels could easily be hidden from view using CSS.

Addendum

There's probably more than one truth in the search for the ultimate date input format.

When the emphasis of the application you are designing is on speed and speed alone, then the single field pattern might be your friend. It's particularly useful for data entry applications in which the person who has to enter the data will have to use the same input form time and time again. In cases where it's a one-off situation in your user's life — E.G.: a birth date that is required on a form to apply for any sort of membership — then the method that I pledged for does seem to be the pattern that has the speediest input while remaining unambiguous. Meeting these two criteria, the Cornelis Hybrid will often be a safe choice.