Re: [whatwg] Forms-related feedback

On Jan 8, 2013 1:47 AM, "Ian Hickson" <ian@hixie.ch> 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 think it more common for people to interact mainly with people in their
own timezone. I.e. most time when talking about dates and times people
don't me nation what timezone is involved and rely on contest to provide
that information.

This applies both professionally, since most people work at single-timezone
companies, or at least single-timezone departments, as well as privately,
since most people interact with friends and family mainly in the same
timezone.

So in most contexts when people think about a point in time, they do so for
a specific timezone.

When that is not the case, this is something that people are aware of. When
I interact with friends/family/coworkers where the timezone is not obvious
this is quite clear. And in these cases I'm aware that I need to specify
timezone.

I think that the same applies to developers.

So I would imagine that when a developer sees "datetime" that does not
include a timezone. Likewise, when a developer wants to ask the user for a
point in time which does include a timezone, that they would remember to
ask for that explicitly.

Additionally, in many cases even when timezones are involved do UIs not ask
for the timezone as part of the date/time picker.

When looking for airplane tickets the timezone is assumed to be that of the
departing location when talking about departing time, and that of the
arrival destination when talking about arriving time.

When renting a car, the same thing applies, even if the car is picked up
and returned in different timezones.

Even the calendar app that's on my device (the built-in calendar app for
Android 4.2) does not ask for timezone as part of the date/time picker.

Instead a separate control is used where the user can choose what timezone
the separately entered date/time is. This makes a lot of sense since
timezones are easy to forget about and so having explicit and separate UI
makes things more unlikely that the user will forget to enter the
information.

This is actually required for repeating events since it's important to know
which timezone the user picked. I.e. there are two values entered by the
user: the date/time and the timezone.

So first off I'm not convinced that the common case for date/time entry
will include entering a timezone. That might be the case in the technology
industry, but is likely not elsewhere.

Second, I'm not convinced that even if the common case includes timezone
entry, that this means that the intuitive behavior for a "datetime" input
type is to include UI for timezone entry.

Third, I think that even in many cases where timezones are involved, that
the better UI is to have timezone entry separate from from the date/time
picker.

I'm not advocating that having a timezone aware date/time picker is a bad
idea. But I don't think it should be the "default" behavior. It might not
even make it into the 80% set of use cases.

So at least we should make "datetime" refer to a timezone-agnostic picker.
And then use "datetime-global" or "datetime-absolute" or some such as a
timezone aware picker.

/ Jonas

Received on Tuesday, 15 January 2013 01:35:19 UTC