- From: Phillips, Addison <addison@lab126.com>
- Date: Thu, 14 Aug 2014 23:01:55 +0000
- To: Leandro Reis <lreis@adobe.com>, Arle Lommel <arle.lommel@gmail.com>
- CC: "www-international@w3.org" <www-international@w3.org>
- Message-ID: <7C0AF84C6D560544A17DDDEB68A9DFB52C2C2FF3@ex10-mbx-36009.ant.amazon.com>
The data value probably should be parsed according to rules in HTML, so it would be true that 2014-06-10T00:00:00+08:00 has the incremental time value equivalent to June 9, 2014 at 4 PM UTC. Then if there is a tz attribute of “America/Los_Angeles” (which is GMT-07:00), that incremental time displays as June 9, 2014 9:00 AM (if I’m doing my maths right). So the tz overrides the LTO of +8 for display, but not for parsing of the value. This would mean that parsers would work without regard for the tz attributes presence or absence and identically to today. The recommendation is to use “Z” (UTC) for timestamps to prevent confusion. Thoughts? From: Leandro Reis [mailto:lreis@adobe.com] Sent: Thursday, August 14, 2014 3:27 PM To: Arle Lommel; Phillips, Addison Cc: www-international@w3.org Subject: 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
Received on Thursday, 14 August 2014 23:02:29 UTC