The format MM/DD/YY is unique to the United States. Most of Europe uses DD/MM/YY. Japan uses YY/MM/DD. The separators may be slashes, dashes or periods. Some locales print leading zeroes, others suppress them. If a native Japanese speaker is reading a US English web page from a web site in Germany that contains the date 03/04/02 how do they interpret it?
Answer
Your first impulse may be to assume this problem will be taken care of during localization of the web pages - i.e. let the translator fix it. Resist this impulse. Do you really want to keep separate copies of documents for the U.S. and the U.K. that differ only in date format? In any case you still have to deal with multilingual users like the one in our example above.
You have three options to consider, all with advantages and drawbacks:
Use a locale neutral format
Make the month and year obvious
Use the Accept-Language HTTP header
Option One: Use a locale neutral format
ISO 8601 specifies a format of YYYY-MM-DD. 2003-04-02 is clearer than 03/04/02. (Some prefer to modify ISO 8601 by using an abbreviation for the month to make it more clear, for example 2003-Apr-02, but then it is no longer locale neutral.).
Pros:
This method is unambiguous.
ISO 8601 is computer friendly. Doing a standard character sort on a list of dates gives you a chronologically ordered list.
Cons:
ISO 8601 is people unfriendly. People are comfortable with their "natural" date formats.
It takes more space. For a date in a paragraph of text this is no big deal. If a document is a table with some columns containing dates the extra space might become an issue, especially if you've designed a layout that is already pressed for space.
This may be particularly user unfriendly in countries where an alternative calendar is used (eg. Thailand favours the Buddhist calendar).
Option Two: Make the month and year obvious
To do this use a name for the month (abbreviated or not) and use 4 digits for all Gregorian year numbers. For example, 2 April 2003.
Pros:
This method is completely unambiguous.
It is people friendly. People are comfortable with their "natural" date formats.
Cons:
It is less computer friendly when it comes to sorting, etc.
It takes more space. In some locales even the abbreviation for a month name may be longer than three characters. (In French the first three letters of June and July are the same, Juin and Juillet). Allowing extra space for this exacerbates the space problem.
Option Three: Use the Accept-Language HTTP header
The HTTP Accept-Language header only specifies the user's language preferences, but is commonly used to determine locale preferences as well.
This method works well for dynamically generated web documents when inserting a date from some back-end storage into a page, as long as the user's expectations of date format are clear. Appropriateness is a function of the linguistic context rather than simply the user's browser settings. For example:
Inserting a date from a database into a Japanese page with a Japanese format would be very helpful for the user.
A Japanese person reading the generated date 03/04/02 in an English document might mistakenly assume that this used an English ordering.
Displaying a generated date in a Japanese date format such as ２００３年４月２日 in an English page would probably look out of place.
How this is done will vary depending on your development environment. Here are some pointers for some common environments.