Difference between revisions of "HTML5TimeZone"

From Internationalization
Jump to: navigation, search
Line 4: Line 4:
 
== Introduction ==
 
== Introduction ==
  
A gap in HTML is that date and time values cannot be represented using actual time zone identifiers.  
+
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.
  
The various time values in HTML can include zone offsets. For example, you can have a time value such as <code>2014-06-19T07:10:16-07:00</code>, which indicates a time that is offset from UTC by 7 hours (and is approximately the same as the Pacific Daylight Time in the USA at that time of year).  
+
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.  
  
However, for many time values, 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. This is particularly true when working with recurring events or when converting visual "time picker" controls to a date object. For more background, see [http://www.w3.org/TR/timezone Working with Time Zones].
+
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.  
  
For example, future dates cannot be correctly represented by an offset alone, as noted in section 4.3 of [http://www.w3.org/TR/timezone]. 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.
+
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:
 
This document proposes to extend time-bearing elements in HTML to allow a time zone identifier. The affected elements appear to be:
Line 30: Line 34:
 
     &lt;time dateTime="2014-04-19" tz="Asia/Tokyo"&gt;April 19&lt;/time&gt;
 
     &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, the <code>tz</code> attribute overrides the offset for handling and display of the time value. For example:
  
==== Con ====
+
    &lt;time dateTime="2014-04-30T12:10:11-07:00" tz="Europe/London"&gt;
  
One negative of this approach is that time values in elements such as <code>time</code> might include an offset that is not consistent with the <code>@tz</code> attribute. Rules for conflict resolution would be necessary in this case.
+
The above is interpreted or displayed by the user-agent using the time zone "Europe/London", even though the time value has an offset of GMT-7.
  
 
== Other Alternatives ==
 
== Other Alternatives ==

Revision as of 16:01, 14 August 2014

Related to ACTION-149

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, the tz attribute overrides the offset for handling and display of the time value. For example:

   <time dateTime="2014-04-30T12:10:11-07:00" tz="Europe/London">

The above is interpreted or displayed by the user-agent using the time zone "Europe/London", even though the time value has an offset of GMT-7.

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.