- From: TAMURA, Kent <tkent@chromium.org>
- Date: Wed, 16 Jan 2013 13:47:12 +0900
- To: Ian Hickson <ian@hixie.ch>
- Cc: whatwg <whatwg@whatwg.org>
On Wed, Jan 16, 2013 at 11:20 AM, Ian Hickson <ian@hixie.ch> wrote: >> * 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. Yeah, I agree with it. But I as a developer in a browser vendor don't want to implement such almost-impossible UI even though type=datetime-local is enough in many cases and type=datetime is rarely used. >> 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. I don't think so. If you make a repeating event in a region with daylight saving time, Google Calendar respects the local time which you specified. -- TAMURA Kent Software Engineer, Google
Received on Wednesday, 16 January 2013 04:47:58 UTC