What is the request here?

(Sometimes you need a floating time. For example, when asking the user for a time on an alarm clock, the time has to be in the user's local time zone regardless of what that is, and needs to "float" if the user changes time zone. Similarly, flight booking sites might ask for the user's airports and preferred departure or arrival date and times, and would do so without a time zone so that they could automatically adjust the time to the actual UTC time based on the airports' time zones.)

Please see Addison's feedback in https://www.w3.org/Bugs/Public/show_bug.cgi?id=16960 .

The way I understand it, it's both a problem of naming (it's not really a "local" date and time, but a "floating" date and time), as well as a request for an example (like the two you gave in #c1).

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

(In reply to comment #3)
> (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.

The use of the therm "floating time" seems compelling to me. It's not even something that has to be defined in the HTML spec, since it's defined here: http://www.w3.org/TR/2011/NOTE-timezone-20110705/#floating and also here: http://www.ietf.org/rfc/rfc2445.txt and seems a commonly used term in coding, eg. http://search.cpan.org/~drolsky/DateTime-TimeZone-1.60/lib/DateTime/TimeZone/Floating.pm and applications, eg. http://www.macobserver.com/tmo/article/Understanding_iCal_Time_Zones.

It's more concrete than "local date and time", because the determination of "local" implies a point of reference. Thus, we'd need to specify whether it's with reference to the local time zone of the browser - or the local time zone of the server or some other reference point. We, in fact, want the opposite: we want something that has no time zone and no point of reference. 

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

It depends on when the mapping to a wall-clock time happens. A "local date and time" implies that the mapping happens at the time of input/selection in the browser. After that, the time zone is fixed. In contrast, a "floating time" implies that there is no time zone and it's always mapped at the time of display, which is more accurate.

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

"floating" works for me and was also what you used in #c1 to explain what 'local dates and times' means.

(In reply to comment #4)
> 
> The use of the therm "floating time" seems compelling to me.

Unfortunately it's often wrong. Most use cases for type=datetime-local are cases with an explicit or implicit time zone. For example, an airline flight picker would use type=datetime-local, with the time zone implied by the airport code.


> It's not even something that has to be defined in the HTML spec, since
> it's defined here

I'm not sure how that would affect this one way or the other.


> It's more concrete than "local date and time", because the determination of
> "local" implies a point of reference.

There often is a point of reference.


> Thus, we'd need to specify whether it's with reference to the local time zone
> of the browser - or the local time zone of the server or [...]

It varies on a case-by-case basis.


> We, in fact, want the opposite: we want something that has no time zone
> and no point of reference. 

That is contrary to the point of this type.


> It depends on when the mapping to a wall-clock time happens. A "local date
> and time" implies that the mapping happens at the time of input/selection in
> the browser.

Right.


> After that, the time zone is fixed.

In most cases, but not necessarily.


> In contrast, a "floating
> time" implies that there is no time zone and it's always mapped at the time
> of display, which is more accurate.

More accurate for some uses, but not all.


> "floating" works for me and was also what you used in #c1 to explain what
> 'local dates and times' means.

I gave two examples in comment 1; the first is a floating time, the second is not.



I'm marking this WONTFIX since this is also covered by a WHATWG thread that I just responded to, and I'd rather not discuss this in two locations. If you have further information to add, please respond on the WHATWG thread. Thanks.