Re: HTML Time Zone proposal

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<mailto:arle.lommel@gmail.com>>
Date: Thursday, August 14, 2014 at 2:15 PM
To: "Phillips, Addison" <addison@lab126.com<mailto:addison@lab126.com>>
Cc: "www-international@w3.org<mailto:www-international@w3.org>" <www-international@w3.org<mailto:www-international@w3.org>>
Subject: Re: HTML Time Zone proposal
Resent-From: <www-international@w3.org<mailto: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