HTML5TimeZone

Introduction

A gap in HTML is that date and time values cannot be represented using actual time zone identifiers. The I18N WG note 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 2014-04-30T07:10:16-07:00, 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 America/Phoenix 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:

<time>
<input type=date>
<input type=time>

Proposal

Add the attribute tz 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 tz attribute specifies the time zone ID to apply to a time bearing field. Its value must be a valid IANA time zone ID, the string auto, the string UTC, or the empty string. The string auto signifies the local time zone of the user-agent. The string UTC 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 tz attribute, UTC should be applied.

The tz 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, duration values do not have any specific relationship to incremental times. Other values such as month or week are generally used in a "floating time" context rather than referring to a specific time zone basis. However, use of the tz attribute is permitted with any time value.

Example:

   <time dateTime="2014-04-19" tz="Asia/Tokyo">April 19</time>

When the tz 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 tz attribute for the purposes of conversion to incremental time. The tz 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:

   <time dateTime="2014-06-10T00:00:00+09:00" tz="America/Los_Angeles">

The value of dateTime 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 14695BE1180L for a call to getTime() 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 tz 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 [1] to include the new syntax.

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

   "1979-10-14T12:00:00.001@America/New_York"
       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.

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.