[whatwg] 'datetime-local' and 'datetime' comments

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'