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 13:47:12 +0900
Message-ID: <CAGH7WqGV9wZJtRw96Ymv3NHwNdYUMHR2UWUAKJ+BhFT0GVVnBA@mail.gmail.com>
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.

Software Engineer, Google
Received on Wednesday, 16 January 2013 04:47:58 UTC

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