Date formats

Updated

Question

How do I prepare my web pages to display varying international date formats?

Visitors to a web site from varying locales may be confused by date formats. The format MM/DD/YY is unique to the United States (but sometimes used in Canada, too, which can obviously create some confusion there). 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:

  1. Use a locale neutral format
  2. Make the month and year obvious
  3. 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:

Cons:

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:

Cons:

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:

How this is done will vary depending on your development environment. Here are some pointers for some common environments.

Java/JSP

Call the getLocale method of the ServletRequest or HttpServletRequest object. Use the returned Locale object to call DateFormat. Note that the SHORT format uses only numbers. If you want unambiguous formats use FULL. In some locales even LONG is all numeric.

See also ICU4J since it contains more up-to-date data (and more functionality) than the JDK routines.

ASP

Use Request.ServerVariables('HTTP_ACCEPT_LANGUAGE') to get the user's preferences. Parse the first locale from the list of accepted locales. You'll have to do your own mapping from the alphabetic locale code to a numeric Locale Identifier. Set Session.LCID to the resulting value. Call FormatDateTime to format the date.

Use vbLongDate to avoid ambiguity.

Perl

Use $ENV{'HTTP_ACCEPT_LANGUAGE'} to get the preferred language. Use POSIX:strftime to format date values. You'll have to do your own mapping of the accepted languages value to a date format string.

Summary

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.

By the way

Some have advocated the creation of a date tag that would display dates according the locale of the user agent. This is subject to the same practical issues as described for dynamic date generation with the Japanese example. The appropriate format is generally a function of the linguistic context of a page, rather than the user's platform.