Bugzilla – Bug 16960
i18n-ISSUE-89: Time zones and local dates and times
Last modified: 2014-08-22 15:22:45 UTC
22.214.171.124 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.
This bug was cloned to create bug 17856 as part of operation convergence.
Addison, I understand that this may be problematic, but can you please clarify what you would like us to do about it?
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.
Addison, could you please review the discussion in bug 17856 and see if that resolves your issue?
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:
The change to remove input type="datetime-local" has been committed to HTML5.1 master. Please review:
Back-porting this change to HTML5.0 CR branch:
Leaving active as there is some concern raised with this change
Removed the CR keyword as this is addressed for CR.
It was noted at the F2F that this feature is at risk.