RE: <input type=datetime-local> HTML5 CR bugs

Hi Travis,

Sorry to be behind in responding. The holidays and such have impacted our timing. And I must admit that I missed the original message.

Our WG teleconferences are Thursdays, so we will reply to you following a WG discussion tomorrow.

Addison

From: Travis Leithead [mailto:travis.leithead@microsoft.com]
Sent: Wednesday, January 22, 2014 10:38 AM
To: Paul Cotton; www-international@w3.org
Cc: public-html@w3.org
Subject: RE: <input type=datetime-local> HTML5 CR bugs

Having heard only silence, I must conclude that the proposal stated in the mail below is acceptable. (I’d much rather have an active acknowledgement though—please take the time to read and respond if you have feedback!)

My next step, in the absence of active feedback is to prepare the proposed changes for this group to review. ETA roughly 2 weeks.

From: Paul Cotton
Sent: Tuesday, January 21, 2014 6:26 PM
To: www-international@w3.org<mailto:www-international@w3.org>
Cc: Travis Leithead; public-html@w3.org<mailto:public-html@w3.org>
Subject: RE: <input type=datetime-local> HTML5 CR bugs

Could you give the HTML WG some idea of when you will be able to respond to this email thread about the quoted HTML5 CR bugs?

/paulc

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329

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