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

[whatwg] datetime and datetime-local (was: Re: Forms-related feedback)

From: Mounir Lamouri <mounir@lamouri.fr>
Date: Wed, 30 Jan 2013 19:27:35 +0000
Message-ID: <51097427.1040501@lamouri.fr>
To: whatwg@whatwg.org
On 08/01/13 00:47, Ian Hickson wrote:
> On Tue, 27 Nov 2012, Mikko Rantalainen wrote:
>> Ian Hickson, 2012-11-22 07:15 (Europe/Helsinki):
>>> On Wed, 21 Nov 2012, Mounir Lamouri wrote:
>>>> Then, maybe a better naming could be "datetime-utc"?
>>> I think that would mislead authors into thinking that the UI that 
>>> users will see is one that asks for a UTC time. That kind of UI is the 
>>> worst UI for this kind of feature, so that would be misleading.
>> I'd suggest "datetime-absolute" because the other variant is "floating" 
>> or "relative" (to local politically decided time which may vary 
>> depending on future political decisions).
> We could rename "datetime" to "datetime-absolute" and leave 
> "datetime-local" as named, but I'm not really convinced that's much better 
> than what we have now.

I feel like there is some consensus in the list to move 'datetime' to a
TZ-agnostic type. If Gecko and Webkit (via Tamura Kent) would be willing
to do so, maybe the specification could be changed that way?

Regarding the TZ-aware type, I believe we could simply drop it from the
specifications for the moment. I do not believe it is a good idea to
specify something when we have no idea how that could be implemented and
when there is no native UI that could be used. The advantage of
'datetime-timezone' compared to 'datetime' + a UI to pick a timezone is
low. In addition, I'm afraid that keeping such a type in the specs in
the hope that someone someday comes with a good implementation might
create the opposite effect and forces the platform to keep an input type
that has overall bad implementations but can't be removed because it is
implemented by most vendors for the sack of "implementing all of html5".

Authors will still able to add the timezone information by having a
separate UI component for it and they will also be able to get the users
timezone from the Date object.

Received on Wednesday, 30 January 2013 19:28:00 UTC

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