View source for HTML5TimeZone


Related to [http://www.w3.org/International/track/actions/149 ACTION-149]

Now tracked by: [https://www.w3.org/Bugs/Public/show_bug.cgi?id=26641 HTML BUG 26641]

== Introduction ==

A gap in HTML is that date and time values cannot be represented using actual time zone identifiers. The I18N WG note [http://www.w3.org/TR/timezone Working with Time Zones] describes various use cases in which local time offset ("time zone offset" in HTML parlance) is insufficient for representing or exchange date or time values.

For example, the various time values in HTML can include zone offsets. Thus, you can have a time value such as <code>2014-04-30T07:10:16-07:00</code>, which indicates an instant of time in April of 2014 that is offset from UTC by minus 7 hours. 

Currently, this is approximately the same as the Pacific Daylight Time in the USA at that time of year. However, it is also the same as Mountain Standard Time (which is observed in the <code>America/Phoenix</code> time zone at this time of the year). That same offset would not be valid for U.S. Pacific Daylight Time in the year 2006 or earlier, since at that time Daylight Savings (Summer) Time did not apply in that time zone. 

Time zone rules change reasonably often and arbitrarily. Time zone identifiers help insulate software from these changes by abstracting the relationship between "wall time" of the event and the internal "incremental time" representation (generally milliseconds from a particular date in UTC). When a time zone identifier is used instead of an offset, the appropriate local time offset from UTC can be computed using the time zone's current and historical information rather than being fixed. In addition, future changes to time zone rules do not require changes to the time zone identifier and can be applied seamlessly, rather than needing to modify the time value.

This can have legal consequences.  Option contracts, for example, have their expiry times given as such-and-such a date, "5 PM New York time" (or "London time"), which protects buyers against the vagaries of time zone changes: what is meant is whatever is 5 PM on that day in the time zone including New York or London. Since the current offset where the user is located may not correspond to that time zone and the current offset in that zone may not apply on the given date (because of, for example, the Daylight/Summer time transition), indicating the actual time zone is necessary in order to have a complete and accurate transaction.

Since the actual time zone rules are useful or important in determining the actual wall time of events or the relationship of a date or time value to UTC, particularly when working with recurring events or when converting visual "time picker" controls to a date object, the page author needs a mechanism for expressing the time zone of a time value.

This document proposes to extend time-bearing elements in HTML to allow a time zone identifier. The affected elements appear to be:

* &lt;time&gt;
* &lt;input type=date&gt;
* &lt;input type=time&gt;

== Proposal ==

Add the attribute <code>tz</code> to time-bearing fields that allows the time zone to be specified. This is backwards compatible, since it will be ignored by unaware user-agents. Suggested text follows.

The <code>tz</code> attribute specifies the time zone ID to apply to a <em>time bearing field</em>. Its value must be a valid [http://www.iana.org/time-zones IANA time zone ID], the string <code>auto</code>, the string <code>UTC</code>, or the empty string. The string <code>auto</code> signifies the local time zone of the user-agent. The string <code>UTC</code> signifies Universal Coordinated Time. The empty string signifies that the time zone is explicitly unknown (and may imply a floating time value). When formatting date and time values with an empty <code>tz</code> attribute, UTC should be applied.

The <code>tz</code> attribute may be used with any time value. However, the attribute has less meaning with time values that have a less-specific link to incremental time. For example, <code>duration</code> values do not have any specific relationship to incremental times. Other values such as <code>month</code> or <code>week</code> are generally used in a "floating time" context rather than referring to a specific time zone basis. However, use of the <code>tz</code> attribute is permitted with any time value.

Example:

    &lt;time dateTime="2014-04-19" tz="Asia/Tokyo"&gt;April 19&lt;/time&gt;

When the <code>tz</code> attribute and the time zone offset in a time value disagree, time values are handled in the following way.

Parsing of a time value that contains a time zone offset ignores the <code>tz</code> attribute for the purposes of conversion to incremental time. The <code>tz</code> attribute is applied to display of the incremental time and to any time or date controls (such as a picker that shows a calendar) that the user agent may use to render the time or allow it to be set in a form.

For example, consider this element:

    &lt;time dateTime="2014-06-10T00:00:00+09:00" tz="America/Los_Angeles"&gt;

The value of <code>dateTime</code> is recorded with an offset similar to that of Japan Standard Time (Asia/Tokyo). This value is equivalent to the date June 9, 2014 at 3:00 AM UTC. A JavaScript Date object extracted from this value would return <code>14695BE1180L</code> for a call to <code>getTime()</code> and other fields (such as day or hour) would be consistent with the UTC time.

A user agent displaying this value, however, would apply the </code>tz</code> attribute. For the date shown, the time zone America/Los_Angeles has a local time offset of -07:00. So this dateTime value would be shown as something like "June 9, 2014 8:00 AM PDT".

== Other Alternatives ==

The most obvious alternative would be to establish an extension of ISO8601's syntax that incorporates time zone identifiers directly into date and time values. This extension would then be incorporated into HTML by modifying or extending the formats in the "Dates and Times" section of HTML5 Common Microsyntaxes [http://www.w3.org/TR/html5/infrastructure.html#dates-and-times] to include the new syntax.

For example, one might define a valid zone ID extension to use an "@" sign as a separator: <code>@America/Los_Angeles</code>. A full datetime example might be:

    <code>"1979-10-14T12:00:00.001@America/New_York"</code>
        One millisecond after noon on October 14th, 1979, in the Eastern Time Zone of the USA.

The problem with this approach is: existing browsers or servers that receive these values would reject them as malformed or otherwise fail to parse them correctly.

<hr/>
==== Acknowledgements ====

Thanks to the following for helpful comments during the development of this document: Norbert Lindenberg, Richard Ishida, John Klensin, John Cowan, Arle Lommel, Leandro Reis, as well as other members of the I18N WG or IG who have contributed to this document, the time zone note, and related documents.