Re: HTML Time Zone proposal

Hi Leando,

My concern about having tz override the offset entirely is that it would create a situation where the same HTML string would have a different semantics in different user agents depending on whether they support tz or not.

For example, if we have the existing example:

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

and we have one user agent (perhaps a special-purpose tool for data mining) that doesn’t understand tz and a newer one that does and both are taking data found on the web and adding it to a database, then the older one will interpret that string as being fundamentally different in meaning from what the newer one will parse. In addition, we would have no way of knowing what is actually intended if data is aggregated (e.g., two different processes add the dateTime and tz attributes, which isn’t an entirely far-fetched use case, as my example below will show).

Then let’s consider the following:

<time dateTime="2014-04-30T12:10:11+12:45" tz="Europe/London">

The offset of Chatham Islands Time is so unusual and specific that I think we’d be hard pressed to conclude that this construction wasn’t created specifically with that locale in mind somehow. Using tz to override something that specific would be a red flag to me that the data is malformed if tz is intended to replace the offset.

As far as a use case, I can think of one I might actually use:

I write a script that pulls in a bunch of data with times embedded in it and aggregates it. These data have a variety of offsets, which makes it difficult to compare them, so I use a simple JQuery script (one line would be sufficient) that adds the attribute tz="Europe/London" to all elements with a dateTime attribute so that they now all show time with a consistent time zone and I don’t have to manually account for offsets.

For me, in any events, the use case is secondary to the fundamental uncertainty of semantic interpretation that a complete override would cause. It would break backwards compatibility with older agents that rely on offsets for time zone handling if tz made a complete override.

Best,

-Arle



> On 2014 Aug 15, at 00:27 , Leandro Reis <lreis@adobe.com> wrote:
> 
> Hi Arle,
> 
> I proposed the addition of this overriding rule to the core i18n WG. My thought is to have the tz value completely override the offset (e.g. interpret as 12:10:11 London time). 
> 
> I hadn’t thought of the conversion option you described. I think it’s a valid option, although I’m struggling to visualize a use case for it. 
> 
> Regards,
> Leandro
> 
> From: Arle Lommel <arle.lommel@gmail.com>
> Date: Thursday, August 14, 2014 at 2:15 PM
> To: "Phillips, Addison" <addison@lab126.com>
> Cc: "www-international@w3.org" <www-international@w3.org>
> Subject: Re: HTML Time Zone proposal
> Resent-From: <www-international@w3.org>
> Resent-Date: Thursday, August 14, 2014 at 2:15 PM
> 
> Hi Addison,
> 
> Overall a nice improvement that addresses my concerns nicely.
> 
>  One new part isn't entirely clear to me now, however:
> 
>> When the tz attribute and the time zone offset in a time value disagree, the tz attribute overrides the offset for handling and display of the time value. For example:
>> <time dateTime="2014-04-30T12:10:11-07:00" tz="Europe/London">
>> The above is interpreted or displayed by the user-agent using the time zone "Europe/London", even though the time value has an offset of GMT-7.
> 
> Does this mean that London time zone completely overrides the offset, i.e., this would be interpreted as 12:10:11 London time? Or does it mean that the time with that offset would be displayed as the London equivalent to 12:10:11 US mountain time on that date (19:10:11 in London)? The text is ambiguous since it is not clear what “handling” means (at least to me). 
> 
> I would hope that it is the latter behavior, but it needs to be clear either way by explicitly stating what the user agent would/should show in this case. 
> 
> Best,
> 
> Arle