Bug 16960 - i18n-ISSUE-89: Time zones and local dates and times
i18n-ISSUE-89: Time zones and local dates and times
Status: ASSIGNED
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec
unspecified
PC Windows NT
: P2 normal
: ---
Assigned To: Travis Leithead [MSFT]
HTML WG Bugzilla archive list
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-07 17:13 UTC by Addison Phillips
Modified: 2014-04-08 23:59 UTC (History)
9 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Addison Phillips 2012-05-07 17:13:18 UTC
2.5.5.4 Local dates and times
http://www.w3.org/TR/html5/common-microsyntaxes.html#local-dates-and-times

This section defines 'local dates and times', which is a date-and-time value *without* a time zone. This type seems problematic because it does not deal with the time zone problem. Its relationship to either floating or incremental times is completely arbitrary. See also i18n-ISSUE-88.
Comment 1 contributor 2012-07-18 07:04:35 UTC
This bug was cloned to create bug 17856 as part of operation convergence.
Comment 2 Robin Berjon 2012-09-18 13:03:48 UTC
Addison, I understand that this may be problematic, but can you please clarify what you would like us to do about it?
Comment 3 Addison Phillips 2012-09-18 15:21:56 UTC
The I18N WG would like you to consider several ways of addressing the issues raised by the 'local date and time' microsyntax. 

One way of addressing it would be to define it in terms of a floating time value, although floating times are usually either a date (with no hour/minute/second value) representing an event such as a birthdate that is not ties to a specific time zone or to a time (with no day/month/year) which can be interpreted as a local wall time in any time zone (such as the time of day to observe the DST transition), rather than a combination of both.

Another would be to mention the problem of time zones and allow implementations to tie the value to a specific arbitrary time zone (probably UTC) when comparing/converting to/from incremental time values. For example, ECMAScript Date values are incremental times (millis since epoch) and the relationship between 'local date and time' and this type of incremental time should be clear.

Note that if this were the case, the name of the microsyntax would be misleading. It's not a 'local date and time' unless it somehow corresponds to local wall time, is it? But if it corresponds to local wall time, then it inherently has a time zone which is most probably not UTC. In that case, the time zone should be explicit and explicitly available.

I am aware that this microsyntax is not an invention of HTML5, but the I18N WG is concerned that the definitions provided make it too easy to create forms and pages that don't handle time values correctly or which change time values in subtle but quite broken ways.
Comment 4 Silvia Pfeiffer 2013-08-09 05:11:35 UTC
Addison, could you please review the discussion in bug 17856 and see if that resolves your issue?
Comment 6 Travis Leithead [MSFT] 2014-02-07 22:53:11 UTC
My plan to resolve this bug is to remove the <input type=datetime-local> control type as it has little independent value, and is the source of potential developer confusion. Outside of that, the "local date and time" section (which would still be used by the HTMLTimeElement) will be changed to use the "floating" terminology. A "health warning" will also be added to help authors avoid using "floating" date/time values improperly.

See additional notes in the mailing list summary:
http://lists.w3.org/Archives/Public/public-html/2014Jan/0072.html
Comment 7 Travis Leithead [MSFT] 2014-02-11 00:30:02 UTC
The change to remove input type="datetime-local" has been committed to HTML5.1 master. Please review:

https://github.com/w3c/html/commit/3e5df1ee1aebed37571a23c9b62adc74a92a04b9
Comment 8 Travis Leithead [MSFT] 2014-02-22 01:43:35 UTC
Back-porting this change to HTML5.0 CR branch:
https://github.com/w3c/html/commit/593c969fede40d8289252e263e0241ec3b98879e

Leaving active as there is some concern raised with this change

Removed the CR keyword as this is addressed for CR.
Comment 9 Sam Ruby 2014-04-08 23:59:13 UTC
It was noted at the F2F that this feature is at risk.