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?
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.
There are two main aspects related to date processing on the Web: how the user enters a date and how the author displays a date. This article will show how to enter a date and how to represent a date in various formats.
Occasionally, websites require the user to fill in the date of an event. Content authors can use either a textbox or a special date picker interface to do that. HTML5 introduced input
elements of type date
, time
, datetime-local
, month
, and week
, which let the user easily enter a date or a time. If you want to choose a range of dates, or deeply customize the UI of the date picker, you can also choose to implement a customized date picker yourself.
If you're using your customized date picker and not planning using the input
element, you need to store it in a standard format like ISO 8601 to be able to share it with others.
Here are examples of native HTML date and time picker interfaces:
Each browser has its own way of rendering these elements, and browsers that do not support them will fall back to a single-line text field.
The date entered in the input is represented using a string. HTML uses a variation of the ISO 8601 standard for its date and time strings. The date and time strings do not include the time zone data. Content authors can get the time zone data using getTimezoneOffset() in JavaScript and store it on the server-side separately if needed.
You can set a default value for the input by using the value
attribute or restrict the date or time using the min
, max
, and step
attributes.
You can get and set the date value in JavaScript with the value
property. For example:
You have four options to consider, all with advantages and drawbacks:
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:
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:
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.
The JavaScript Date
object represent a single moment in time in a platform-independent format. When creating a Date
object, the input should conform to the ISO 8601 format (YYYY-MM-DDTHH:mm:ss.sssZ
). The parsing behaviour with other formats is implementation-defined and may be different in different browsers.
There are several methods in Date
to return a string representation of a particular current date and time in various formats and perform time zone conversions. For example, the toLocaleString
method returns a string with a language sensitive representation of this date:
You can also refer to the Date page on MDN for more information.
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.
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.