On Mon, Jan 14, 2013 at 2:19 AM, Ian Hickson <ian@hixie.ch> wrote: > On Sun, 13 Jan 2013, TAMURA, Kent wrote: >> So, I think it's impossible for us to build reasonable UI for >> type=datetime. It should be removed from the specification. > In the simplest case, the UI for type=datetime doesn't need to be > different from the UI for type=datetime-local. Any differences, IMHO, > would be just accessible from (e.g.) a context menu (to allow the user to > actually pick a time zone). Google Calendar's event editor page has a > pretty good type=datetime widget (though in their case it has two > widgets combined into one, for start and end). I don't think it works well because of daylight saving time. * If the type=datetime UI asks a UTC datetime, type=datetime-local is enough and type=datetime is unnecessary. * 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. * If the type=datetime UI asks a datetime and a timezone offset value, many users don't understand it. The Google Calendar's UI is equivalent to type=datetime-local with an optional timezone selector. I don't know how Google Calendar handles future changes of daylight saving time period. -- TAMURA Kent Software Engineer, GoogleReceived on Wednesday, 16 January 2013 01:03:19 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:12 GMT