[Bug 17856] i18n-ISSUE-89: Time zones and local dates and times

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17856

Ian 'Hixie' Hickson <ian@hixie.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |NEW

--- Comment #3 from Ian 'Hixie' Hickson <ian@hixie.ch> ---
(In reply to bug 16960 comment #3)
> One way of addressing it would be to define it in terms of a floating time
> value, although floating times are usually either a date (with no
> hour/minute/second value) representing an event such as a birthdate that is
> not ties to a specific time zone or to a time (with no day/month/year) which
> can be interpreted as a local wall time in any time zone (such as the time
> of day to observe the DST transition), rather than a combination of both.

Renaming the types at this time is something we could do, but only if the new
name is especially compelling and the old name especially problematic. It's not
clear to me that either of these are true (e.g. see the caveats in the
paragraph above, and note that the definition of "floating" in the paragraph
above does in fact use the term "local" — they're not _that_ different really).
Certainly there are use cases for type=local-datetime that aren't strictly
about "local" values, but there are many that are. A perfect name is difficult
to find here.


> Another would be to mention the problem of time zones and allow
> implementations to tie the value to a specific arbitrary time zone (probably
> UTC) when comparing/converting to/from incremental time values. For example,
> ECMAScript Date values are incremental times (millis since epoch) and the
> relationship between 'local date and time' and this type of incremental time
> should be clear.

The problem of time zones is repeatedly and thoroughly discussed in the
specification already, but if there's anywhere in particular where it should be
discussed but isn't currently, I'm happy to consider adding more. Please be
specific about where such text should be and concrete about what use cases it
should discuss.

I don't think associating a time zone makes sense, though. The whole point of
the value is that it doesn't have a time zone.


> Note that if this were the case, the name of the microsyntax would be
> misleading. It's not a 'local date and time' unless it somehow corresponds
> to local wall time, is it? But if it corresponds to local wall time, then it
> inherently has a time zone which is most probably not UTC. In that case, the
> time zone should be explicit and explicitly available.

The time zone likely _is_ explicit, or at least implicit, in the overall UI,
e.g. if you are picking a preferred time for a flight, you usually give the
time as a local time and give the time zone as an airport code.


> I am aware that this microsyntax is not an invention of HTML5, but the I18N
> WG is concerned that the definitions provided make it too easy to create
> forms and pages that don't handle time values correctly or which change time
> values in subtle but quite broken ways.

We have a broad array of types in the HTML spec to handle most use cases for
times in UI. I agree that it's easy to shoot yourself in the foot with these,
but honestly I think that's more about the fact that times and time zones are
complicated and less about the specifics of HTML's control types.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Monday, 29 July 2013 20:10:39 UTC