RE: <input type=datetime-local> HTML5 CR bugs [I18N-ACTION-279]

I’ve now committed these changes to the HTML 5.1 Master branch. Please look these over and point out any errors or concerns you may have. As always, silence is considered consent. I’ll let these bake in 5.1 for a week or so before starting the process of porting to 5.0 CR in the absence of feedback.

Spec with all three changes incorporated: http://www.w3.org/html/wg/drafts/html/master/ (building now)

Commit for the health warning: https://github.com/w3c/html/commit/6704d9ac2cf55a8eae2b0e12f675d74df4c3d65f

Commit for removing datetime-local: https://github.com/w3c/html/commit/3e5df1ee1aebed37571a23c9b62adc74a92a04b9

Commit for renaming local->floating: https://github.com/w3c/html/commit/22162bf56037c266c78f9c9d77ccd1c8fda40b77


Thanks!

From: Travis Leithead
Sent: Friday, February 7, 2014 2:59 PM
To: 'Phillips, Addison'; Paul Cotton
Cc: public-html@w3.org; www-international@w3.org
Subject: RE: <input type=datetime-local> HTML5 CR bugs [I18N-ACTION-279]

Thank you Addison (and i18n folks)!

My plan of record is therefore the following:


1.      Add a “health warning” about conversion of floating date-times to incremental time in the current “local dates and times” section (2.4.5.5)

2.      Rename “local” to “floating” in section 2.4.5.5 and fix-up related references

3.      Remove the input’s “local date and time” state (4.10.5.1.12) and related reference

I will plan on making these changes to HTML5.1 spec, getting a round of review/feedback, and then porting them back to the CR branch to resolve the three related bugs (16957, 16959, 16960).

-Travis

From: Phillips, Addison [mailto:addison@lab126.com]
Sent: Monday, February 3, 2014 3:53 PM
To: Paul Cotton
Cc: public-html@w3.org<mailto:public-html@w3.org>; www-international@w3.org<mailto:www-international@w3.org>; Travis Leithead
Subject: RE: <input type=datetime-local> HTML5 CR bugs [I18N-ACTION-279]

Hello HTML,

We discussed these issues in a pair of recent teleconferences and I’ve been actioned with replying on our behalf.

In general we agree with Travis’s email. Our concern is, indeed, that “datetime-local” falsely implies local wall time (and thus a time zone). Developers are not good at identifying floating times as it is. Confusing terminology is not helpful.

In addition to the WG’s position, I agree that the health warning doesn’t affect normativeness of the text. It’ll be good to have. I also agree with the list of both pro- and con- arguments for use of a floating datetime input field (items 1-5 below). I would tend to add that coercion to an incremental time is pretty likely to happen if you pull the data into a Date object in JS or on the server unless you are exceedingly careful. Hence the need for health warnings.

To Travis’s conclusions, I would add that floating timestamps (date *and* time are significant) are the least common case. Usually at that point you want to compute a local time value using time zone information. Generally, the use of floating time requires some forethought by developers to keep from getting into trouble. I could support removing datetime-local as a result. If it’s kept, I think I18N would prefer it to be renamed to include the word “floating” instead of the misleading “local”.

Thanks (for I18N),

Addison

Addison Phillips
Globalization Architect (Amazon Lab126)
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.



From: Travis Leithead [mailto:travis.leithead@microsoft.com]
Sent: Monday, January 13, 2014 8:10 PM
To: public-html@w3.org<mailto:public-html@w3.org>; www-international@w3.org<mailto:www-international@w3.org>
Subject: <input type=datetime-local> HTML5 CR bugs

i18n, public-html:

I'm looking at addressing the following 3 HTML5.0 CR bugs:

Bug #16957/i18n ISSUE 85 - Health Warning for conversion to/from incremental time
Bug #16959/i18n ISSUE 88 - local/floating terminology (See also WHATWG #17855 - Won't Fix)
Bug #16960/i18n ISSUE 89 - time zones and local dates/times (See also WHATWG #17856 - Won't Fix)

The first concerns authors that might make the mistake of converting from input type=date (or type=datetime-local) to JavaScript's Date object, which is a conversion from a "floating" time, to an incremental/global time. The suggestion is that a "health warning" be added to warn users of the potential pitfalls.

The latter two concern the syntax and use-cases for the input element's type=datetime-local state. I'll summarize what I believe to be the key points from these two bugs:

1. A syntactic concern about the use of the word "local" in the type=datetime-local attribute and related spec sections. The term "local" might confuse authors into thinking that it means an incremental time (e.g., "absolute" or "global" time) in their "local" timezone (TZ). The bug requests that we consider changing "local" to "floating" in the terminology of the spec section (issue 88).

2. A link to w3.org/TR/timezone on timezone usage should be added to the spec. (issue 88)

3. Concern that the type=datetime-local does not deal with timezones and that its relationship to either floating or incremental time seems arbitrary. (Issue 89)

I think adding the "Health warning" is a fair compromise and doesn't normatively impact the spec. I'll work on this and propose the change later this week. If this is satisfactory, it can resolve issue 85.

Similarly, adding a link to the timezone note, in the relavant parts of the spec seems like a great idea, and will partially address issue 88 (but not all).

The remainder of issue 88 and issue 89, deal with floating/relative time scenarios vs. global/absolute/incremental time scenarios for datetime-local. I'll be the first to admit that I'm no expert here, but what I think this boils down to is 1) whether the floating datetime-local control is useful, and if so, issues with its name.

I'm pretty convinced by what I've read that there are valid scenarios for both "floating" time input as well as "global" time input as articulated by Ian [1].

The spec provides one control for inputting global time, and that is <input type="datetime">. The spec provides a variety of controls for inputting floating time, such as type=date, type=month, type=week, type=time, and of course type=datetime-local.

Of these floating time input controls, the only one that seems to be generating controversy is the last one: datetime-local.

Those advocating for the _usefulness_ of the datetime-local control have made the following points:
1. date and time controls (no TZ) are useful, thus datetime-local as a combination control would appear useful
2. Use cases: phone alarm (where TZ is just-in-time computed), and events celebrated in different TZs at different global times.
3. Adding the local TZ to datetime-local (without conversion to UTC) is not a solution, as it just increases server-side work and introduces potential errors with little benefit (there is no "one size fits all" solution).

Some drawbacks to having a datetime-local control:
4. The option to set both date + time in one control would seem to imply more date (e.g., TZ) than is actually sent--setting up false expectations.
5. The existing floating date/time controls address common use cases without the need for datetime-local, and typically do need to be independent (date separate from time control).

On the naming debate, those in support of the current status-quo:
6. The extra characters "-local" make it harder to chose the version w/out a TZ. "datetime" is expected to be used more. Also datetime maps closer to Date() (in JavaScript) than to datetime-local.
7. The use of "floating" doesn't capture all the use cases (e.g., flight scheduler where TZ is implied isn't really floating in the true sense).
8. "Floating" is already used in "local date and times" section--it would confuse readers and the definition.

A number of arguments were presented for changing the name:
9. "datetime" is literally concat("date","time") and would be what authors expect.
10. The term "local" could be confusing (seems to imply the "local" TZ)
11. "floating" is more commonly understood term to describe the use cases (see i18n note).

It is my opinion that the datetime-local control is superfluous when there is already a separate date and time control for inputting floating time values in the spec. Existing implementations only appear to have appended their "date" control UI together with their "time" control UI, which also makes me doubt the unique value that datetime-local has in practice. Furthermore, most instances where websites today use floating time input (e.g., plane/train scheduling) use a date control and a separate time control. I don't see why having a datetime-local control would provide additional value over the two-control approach on these same sites, and I can imagine that it would make certain features harder to use.

I also think that removing datetime-local would reduce the confusion I've seen behind the use cases for the floating vs. global time input (though it would still be the case that "date"(no TZ)+"time"(no TZ) != "datetime"(TZ)). It seems intuitive that "date" is floating and that "time" is also floating, but once you put them together, people start having different expectations.

[1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-July/040277.html