[whatwg] 'datetime-local' and 'datetime' comments
ian at hixie.ch
Wed Nov 21 21:15:39 PST 2012
On Wed, 21 Nov 2012, Mounir Lamouri wrote:
> On 20/11/12 06:17, Ian Hickson wrote:
> > FWIW, the UI I'd expect for today's datetime, maybe renamed to
> > "datetime-global", would be a date/time picker that works just like
> > the one without a timezone, except that it then converts the time you
> > give into UTC. So far example, I'm in the PST time zone, so if I said
> > November 19th, 5pm, it would send that as November 20th, 1am UTC.
> 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.
> > The idea is to be able to get a precise time from the user without
> > having to worry about what time zone the user's in, and without the
> > user having to worry about what time zone other users are in. This
> > would be very useful for scheduling global events, e.g. when a hangout
> > is to happen, or when a game is to start, etc. I really don't think
> > this is a rare thing. In fact I think mostly it's the one to encourage
> > people to use, which is why it's called "datetime" currently, with the
> > one without timezones, which I think will overall be rarer, having the
> > longer name.
> I feel like the main issue is that we disagree in which type is the most
> used. I guess it highly depends on who you ask. I tend to book way more
> often trains or flights than I arrange meetings.
It's not a question of which is _used_ more, it's a question of which is
_authored_ more. As far as I can tell, the use cases for floating times
are basically cross-time-zone transport facilities, e.g. plane tickets,
while the use cases for absolute times are anything involving coordination
amongst multiple people in multiple time zones, e.g. meetings (in person
or online), game events, product launches, online live streaming events...
You might book more tickets than you organise meetings, but there are far
more people doing cross-time-zone multi-person events than there are
people selling plane and cross-continental plane tickets, IMHO.
> > I agree that existing UIs are unfortunate, but they should be fixed.
> > It would be unfortunate to push people towards the timezone-less
> > control just because we screwed up the UI and then renamed the type in
> > shame.
> What do you think would be a good UI? Does something that would allow
> selecting a date/time in the current user's TZ and then have the
> information sent to the server in UTC would be a good UI?
That would probably be a reasonable first UI. A more mature UI would also
let you pick the time for a specific other time zone (e.g. because you
know you'll be there), or compare multiple time zones at the same time to
pick a time convenient for multiple people, etc.
> But then, there would be no real difference between the "datetime" and
> the "datetime-foo" widget, right?
There doesn't have to be a difference between any of the widgets. They
could all just be a text field. I wouldn't recommend getting rid of all
the values though. :-)
> If the main difference between "datetime" and "datetime-foo" is the
> format of the value we send to the server, can't we simply always send
> the timezone information? So, servers who care about the user's timezone
> could do the conversion, and others could simply ignore the information.
I don't think the controls should be the same.
Even if they were, I don't think we should encourage authors to consider
the time zone field meaningful. That's just asking for errors. Time zone
manipulation can get really complicated. Did you know that Libya just
changed time zone this month? And if you start dealing with things like
daylight savings time, it can become positively ridiculous, having to
track the whims of goverments around the world.
IMHO, we really want all the complicated time zone manipulation to happen
either on the client (where we only have to worry about a small number of
expert implementors), or in display code, where the impact of errors is
just render-time, not in the database. Back-end code should really only
have to worry about one time zone for everything.
Also, it's really weird to have the client send a time and then
intentionally ignore the time zone. That just seems wrong.
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg