- From: Mounir Lamouri <mounir@lamouri.fr>
- Date: Mon, 12 Nov 2012 17:00:15 +0000
- To: whatwg@whatwg.org
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
Received on Monday, 12 November 2012 20:05:15 UTC