Difference between revisions of "HTML5TimeZone"

From Internationalization
Jump to: navigation, search
Line 6: Line 6:
 
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 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). 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].
+
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).  
 +
 
 +
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].
 +
 
 +
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.
  
 
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 20: Line 24:
 
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 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 has no meaning when applied to <code>month</code>, <code>yearless date</code>, <code>week</code>, or <code>duration</code> values.
+
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:
 
Example:

Revision as of 22:53, 8 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 various time values in HTML can include zone offsets. For example, you can have a time value such as 2014-06-19T07:10:16-07:00, 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).

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 Working with Time Zones.

For example, future dates cannot be correctly represented by an offset alone, as noted in section 4.3 of [1]. 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.

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>


Con

One negative of this approach is that time values in elements such as time might include an offset that is not consistent with the @tz attribute. Rules for conflict resolution would be necessary in this case.

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 [2] 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.