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

[Mounir Lamouri]

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