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

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).

> 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...

At least here in Finland, floating times are also used for scheduling
repeating events (e.g. meetings or lectures). I'd much prefer always
scheduling everything in absolute time (UTC) but usually other people
are not happy with that.

A good UI for relative/floating datetime would be to request user to
define date and time without any hint about the timezone.

A *possible* UI for absolute datetime would be to request user to define
date and time in his own timezone (maybe with an option to use UTC
instead) and clearly spell out the timezone in the UI. For example, I'd
be happy to have UI say something along the lines

    Date:
    [2012-11-27]
    Time:
    [10:00:00]
    (Europe/Helsinki)

That would fit perfectly fine on the display of my phone and this would
make it perfectly clear that the event would not happen at 10:00 in London.

>> 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.

I agree. The server should either (a) get relative time which is known
to be floating around and cannot be trusted to mean any absolute time
because floating time is subject to political time zone changes that
sometimes come with very short notice, or (b) absolute time in which
case the server should always get UTC time.

However, I'm not sure how this can be presented to the user. In the
example above I suggested that time input UI should be accompanied with
local time zone ("Europe/Helsinki" in my example). However, that would
suggest that this info would be transferred to the server and that the
server is expected to follow political time zone changes to that
timezone. The user could be assuming that he has defined a specific time
in a specific timezone (an absolute time as far has he knows).

In the reality, the server would like to transfer *the responsibility*
for the possible future time zone changes to the user -- the server
expects user to come by and modify the absolute time in case the user
local timezone has been modified since entering this absolute time. I
have absolutely no idea how on earth this could be explained to casual
user. And even if it could be explained, I'm pretty sure the end user
wouldn't be happy with that responsibility.

As a server software developer, I'd *love* to have timezone-absolute but
I'm not sure how that would ever work in practice (given that
politicians keep up modifying local time at will).

The next best choice would be to have datetime-with-timezone but
unfortunately

(1) Official database for all timezones does not exist
(2) Official timezone names (or labels) do not exist
(3) Timezones are subject to future political decisions

The problems (1) and (2) make transferring the timezone information from
the end user to the server very problematic and the problem (3) makes
any work to fix (1) and (2) a bit pointless. This is because even if UA
could successfully inform the server about the correct timezone, the
server could be using a week old timezone data that is not up to the
latest political events. Or the server might be using latest timezone
data but the UA could be using three year old data. In either case, the
absolute time in UTC could be different for the server and UA.

-- 
Mikko

Received on Tuesday, 27 November 2012 08:26:00 UTC