Am I IIT in in a I'll j
I amiuin in the uKai it
quid
Renoir Boulanger
Software Frontend developer
https://renoirboulanger.com/#is
~
~
On Jul 29, 2013 7:21 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 14 Jan 2013, Jonas Sicking wrote:
On Jan 8, 2013 1:47 AM, Ian Hickson i...@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 mention what timezone is involved and rely on context to
provide that information.
I agree that that is accurate for when people talk. But that's somewhat
misleading, I think, regarding what it implies about form controls.
In Web apps, there's basically three cases:
1. Cases where you mean a specific global time (a time relative to UTC),
for coordination amongst people from many locations.
For example: the time that a broadcast begins
e.g. a live Hangout on G+
the time that a deliverable is due
e.g. the due date for a poetry contest
the time that a resource becomes available and the time
it stops being available, if scheduled in advance
e.g. the time that a meeting phone bridge code starts
working and the time it ends working
2. Cases where you mean a specific global time (a time relative to UTC),
but where the time is really only relevant for local purposes, and so
when given is likely to be given relative to an implied time zone.
For example: the time that a plane takes off or lands
the time that a physical meeting (not one involving
video conferencing across multiple sites) begins
the time that someone wants to go home from work
3. Cases where you mean a floating time and no time zone actually applies.
For example: a wake-up alarm on a phone (wake me up at 8am on
Monday, where the time zone isn't decided until
Monday, by examining where the user is)
the time for an event celebrated at different times in
different time zones, e.g. New Year's.
Now, when implementing these, there's often mistakes made. For example,
authors will often confuse case 1 for case 2, and will often confuse case
2 for case 3. That is, they will often assume a time zone when one should
not be assumed, and will often forget about time zones entirely when a
time zone should be assumed.
For example, they may ask for the time that a broadcast begins, and then
just assume that the time zone is the time zone of the server. This would
work fine in a single-time-zone-company where the server is colocated with
the users. Similarly, they might ask for the time of a plane's departure,
and then display it in the user's time zone, forgetting that there's an
implied time zone given by the user's location.
The opposite error is harder to make. It's harder to ignore the time zone
when all times that the user enters get converted to UTC -- unless you're
in the UK during the winter, or one of a handful of other countries using
UTC, you're likely to notice right away (and even in those, in many cases
you'll likely notice within 6 months).
Because of this likelihood for mistakes, the controls are designed so that
forgetting a time zone requires more characters than giving one. Authors
are less likely to initially use datetime-local than datetime, so they're
more likely to be reminded to use time zones immediately, than they are to
forget to use time zones until too late.
So in most contexts when people think about a point in time, they do so
for a specific timezone.
I don't know how to evaluate if this is true.
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 don't know that that's the case. I think it's more likely that authors
will incorrectly forget to use time zones
