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

Re: [whatwg] Forms-related feedback

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Tue, 30 Jul 2013 10:36:38 +1000
Message-ID: <CAHp8n2keei1OdA_Cu371NHzcap2TnovWFaVJ8DeMX-hcUPxeYQ@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: WHAT Working Group <whatwg@whatwg.org>, Ian Hickson <ian@hixie.ch>, Jonas Sicking <jonas@sicking.cc>
On Tue, Jul 30, 2013 at 9:59 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Mon, Jul 29, 2013 at 4:50 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> Ian, has *any* implementer expressed a preference for implementing a
>> picker which allows selecting date+time+timezone? I.e. one that
>> returns UTC dates?
>
> The Gmail time-picker (when you indicate that you want to set
> timezones), gives you three things next to each other, for date, time,
> and timezone.
>
> These are all right next to each other - whether they're separate or
> combined widgets isn't observable unless you check out the code.

The iCal one allows for selecting a specific time zone and a
"floating" one (which is what is currently called "local"):
http://www.macobserver.com/tmo/article/Understanding_iCal_Time_Zones

I actually think we need to distinguish between local and floating time zones.

When using datetime-local, I would actually expect that the browser
picks the local timezone as the default time zone, so doesn't expose a
timezone entry in the UI. The value that is returned by the form,
however, actually has a timezone.

In contrast, when the app doesn't want a timezone, the developer
should probably use something like datetime-floating. Then, it's clear
that the time zone is actually left off of the returned value, too.

Silvia.
Received on Tuesday, 30 July 2013 00:37:22 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:03 UTC