This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
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?
Historical: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-November/037879.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-July/040277.html
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
The change to remove input type="datetime-local" has been committed to HTML5.1 master. Please review: https://github.com/w3c/html/commit/3e5df1ee1aebed37571a23c9b62adc74a92a04b9
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.
It was noted at the F2F that this feature is at risk.
HTML5.1 Bugzilla Bug Triage: Works for me In the current HTML5.1 spec, the input type=datetime-local value is back. However the floating time language is present. Removing datetime-local from 5.0 may not have been the best move, since I later learned that type was widely used on mobile devices. So, we have interop with Edge, and Chrome implement, Firefox stable does not, not sure about Safari. Seems a little heavy-handed now to remove it. If this resolution is not satisfactory, please copy the relevant bug details/proposal into a new issue at the W3C HTML5 Issue tracker: https://github.com/w3c/html/issues/new where it will be re-triaged. Thanks!