Re: HTML Time Zone proposal

To be clear, this is how I envision the semantics of the four cases:

1: -tz, -offset

<time dateTime="2014-04-30T12:00:00">

12:00 noon at some (unspecified) local time
Cannot be resolved to UTC because we don't know an offset or a tz

2: +tz, -offset

<time dateTime="2014-04-30T12:00:00" tz="Europe/London">

12:00 noon at London time (UTC+1 at that point in time)
= 11:00 UTC

3: -tz, +offset

<time dateTime="2014-04-30T12:00:00-5:00">

12:00 noon wherever UTC-5 is observed at that time (e.g., Chicago)
=17:00 UTC

4: +tz, +offset

<time dateTime="2014-04-30T12:00:00-5:00" tz="Europe/London">

The time in London (UTC+1 at that point in time) that corresponds to 12:00 noon in UTC-5
= 18:00 (Europe/London) = 17:00 UTC

(For completeness, 4a (Leandro’s original proposal): +tz, +offset

<time dateTime="2014-04-30T12:00:00-5:00" tz="Europe/London">

12:00 noon in London (UTC+1 at that point in time)
= 11:00 UTC)


The difference in the behavior of tz in #2 and #4 would actually be attributable to the differences in the time strings, not to tz being inconsistent:

In number 2, the base case is "we don't know what the absolute time referred to in the time string is" so tz simply takes it as local in the indicated time zone.
In the fourth case the absolute time is known, but again, tz makes it local (which involved converting it because we do know the fixed point)

None of these cases invalidates the overall purpose or premise.

Option #4 is the only problematic case because the first three are clear in their meanings. But #4 would result in a different meaning in a system that is aware of tz and one that is not aware of it. So if we understand tz as overwriting the offset, it will mean that the two systems will not agree on what that element means. (Technically, the same is true for #1 and #2 since #1 cannot be resolved to a fixed point in time, but that problem means that we cannot avoid that problem, although we can avoid the conflict in the case of #4).

But there is no reason we can't have a meaningful semantics for this:

<time dateTime="2032-04-30T12:00:00-5:00" tz="Europe/London">

In this example the semantics would be "Whatever time in London will correspond to 12:00 UTC-5 on that date)".

Granted it is something of an edge case, and option #2 would probably make more sense. And I think we would probably all agree that is the way to go.

Best,

Arle