- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 16 Jan 2013 02:20:16 +0000 (UTC)
- To: "TAMURA, Kent" <tkent@chromium.org>
- Cc: whatwg <whatwg@whatwg.org>
On Wed, 16 Jan 2013, TAMURA, Kent wrote: > > * If the type=datetime UI asks a UTC datetime, type=datetime-local is enough > and type=datetime is unnecessary. Yes, asking for a UTC datetime would be horrible UI. > * If the type=datetime UI asks a datetime and a timezone offset value, > many users don't understand it. Yes, asking for a timezone offset would be terrible UI. > * If the type=datetime UI asks a local datetime, UA needs to convert local > datetime to UTC datetime, of course. > However, it's very hard to implement. > ** The UI needs extra work for edge cases of daylight saving time - > standard time switching. > ** A local computer doesn't have complete information of daylight saving > time period of every year. Yes, it's hard to implement. But someone has to do it. I'd rather it was you and a handful of other browser vendors than a million Web authors. The harder something is to do, the more valuable it is for browser vendors to be the ones to do it rather than the site authors. > The Google Calendar's UI is equivalent to type=datetime-local with an > optional timezone selector. The key difference is that Google Calendar converts the time to UTC on the backend. That's not the same as type=datetime-local with an optional timezone selector. In fact it's the precise key difference between datetime-local and datetime. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 16 January 2013 02:20:40 UTC