- From: TAMURA, Kent <tkent@chromium.org>
- Date: Tue, 13 Nov 2012 18:42:30 +0900
- To: Mounir Lamouri <mounir@lamouri.fr>
- Cc: whatwg <whatwg@whatwg.org>
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@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
Received on Tuesday, 13 November 2012 09:45:00 UTC