RE: HTML Time Zone proposal

Hi Yoshito,

The most recent revision, I hope, does that. The @dateTime value is parsed separately. Since no time zone is specified in the given example, UTC is used/assumed when converting to incremental time (or should be). This value can then have a time zone applied to it for display purposes, although this would not be consistent with a floating time value: It is not what the examples in [1] suggest happens, for example.

I think it would have a negative impact to allow the @tz to coerce how @dateTime is parsed. I think it is better to carefully define how these values are handled by user agents than to make it undefined.

In particular, in my own implementations, I explicitly use UTC for floating time values. This makes it a lot easier to code in languages such as Java or JavaScript where one is obliged to use incremental time values or, when using field-based times, obliged to provide a time zone. It is still up to the developer to remember (directly or via reflection) that the value is supposed to be floating and had a special relationship to specific incremental time values and/or time zones.

Addison

[1] http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element



From: yoshito_umaoka@us.ibm.com [mailto:yoshito_umaoka@us.ibm.com]
Sent: Monday, August 18, 2014 11:22 AM
To: Phillips, Addison
Cc: www-international@w3.org
Subject: Re: HTML Time Zone proposal

I have one comment to the proposed specification.
When a wall time is specified with a zone, the time might be invalid, or ambiguous during daylight saving transition (or zone offset change). For example,

1) <time dateTime="2014-03-09T02:30:00" tz="America/New_York"/>

The wall time 2:30 does not exist, because wall time jump to 3:00am (UTC-4) one second after 1:59am (UTC-5)

2) <time dateTime="2014-11-02T01:00:00" tz="America/New_York"/>

The wall time 1:00 happens twice - 1:00am (UTC-4) and 1:00am (UTC-5), so the actual time is ambiguous.


I think the spec should clarify how user agent should handle these cases (invalid / ambiguous), or just say "the behavior is undefined".


- Yoshito Umaoka