- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Tue, 30 Jul 2013 10:36:38 +1000
- 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