W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2013

Re: [whatwg] Forms-related feedback

From: TAMURA, Kent <tkent@chromium.org>
Date: Wed, 16 Jan 2013 10:02:33 +0900
Message-ID: <CAGH7WqEpFzUsvO17qWPm12EVf_=bNtZZ4kFwPzMH_CPVJSG-zg@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: whatwg <whatwg@whatwg.org>

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.

Software Engineer, Google
Received on Wednesday, 16 January 2013 01:03:19 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:52 UTC