[whatwg] 'datetime-local' and 'datetime' comments

[TAMURA, Kent]

The current UI implementations of Opera, iOS, and Chrome-Android spoil the
HTML standard. Web authors hardly have motivation to use type=datetime.
They can add 'UTC' text, and their code can append 'Z' to values easily.

I agree that the type names are not good.  People must think type=datetime
is a combination of type=date and type=time. It's not too late to rename
datetime-local to datetime because the number of type=datetime or
type=datetime-local in the Web is terribly smaller than the number of
type=date.


On Tue, Nov 13, 2012 at 2:00 AM, Mounir Lamouri <mounir at lamouri.fr> wrote:
> Hi,

> We've been working on implementing date and time input types attributes
> at Mozilla this summer and we found out that 'datetime-local' and
> 'datetime' have a quite odd behaviour.

> 'date' and 'time' are both timezone agnostic types: you just set a time
> and date and we assume that it is relative to something. So, it seems
> somewhat natural to assume that 'datetime' would be simply those types
> added to each other. Instead of that, 'datetime' has a notion of
> timezone and 'datetime-local' is the timezone agnostic type.

> In addition of being more intuitive, it seems that a huge majority of
> date/time usage are timezone agnostics because, usually, the timezone is
> implicit. For example, booking flight/train tickets.
> There is however some use cases I can think of, like scheduling a
> meeting, where, sometimes, you might want to mess with timezones. But
> those are quite rare.

> Furthermore, there are currently two implementations for 'datetime' and
> 'datetime-local' I can think of:
> - Opera: 'datetime' is like 'datetime-local' except that there is a
> greyed 'UTC' text next to the datetime picker;
> - Chrome Android: 'datetime' is exactly like 'datetime-local'.
> I haven't checked what is actually sent when the form is submitted by
> those implementations.

> Last but not least, I have never seen any [good and simple] UI allowing
> me to pick a date and time in a specific time zone. As far as I know,
> there are no native UI for those things even on mobile where there are
> UI for date and time pickers.

> As a conclusion, given the lack of good UI and good implementations, I
> think we should change the behaviour of 'datetime' to match the
> behaviour of 'datetime-local' so developers don't use the former and
> falsely expect the behaviour of the later.
> Also, I would suggest that we remove 'datetime-local' from the
> specifications. If later if find out that we really need a date-time
> picker that is not timezone agnostic, we could add something. For the
> moment, given the state of the implementations and the very tiny use
> cases that could solve, I think having this type would hurt more than
> help.

> Thanks,
> --
> Mounir



-- 
TAMURA Kent
Software Engineer, Google