Re: Call for comments: HTML5.x time zone proposal [I18N-ACTION-327]

--On Wednesday, August 13, 2014 17:54 +0100 Richard Ishida
<ishida@w3.org> wrote:

> On 08/08/2014 16:50, Phillips, Addison wrote:
>> All,
>> 
>> The Internationalization WG has been working on addressing a
>> long-standing gap in HTML time and date values, which is the
>> lack of accurate/complete time zone identifiers. Time values
>> can contain the UTC (GMT) offset, which allows most
>> "timestamps" to be complete. However, some situations call
>> for the additional information conveyed by the actual time
>> zone rules. See [1] for examples.
>> 
>> This item is tracked against HTML.next by [2]
>> [I18N-ISSUE-89]. The working group has developed a proposal
>> in response to this issue. The Internationalization WG would
>> like comments from the community. You can find the proposal
>> here:
>> 
>>     https://www.w3.org/International/wiki/HTML5TimeZone
>> 
>> Please send comments to this list *before* next Thursday, 14
>> August.
>> 
> 
> [forwarding comments sent to the wrong list]
> 
> 
> On 25/07/2014 21:04, Phillips, Addison wrote:
>  > For this coming week's teleconference, please review:
>  >
>  > https://www.w3.org/International/wiki/HTML5TimeZone
> 
> "For example, you can have a time value such as
> 2014-06-19T07:10:16-07:00, which indicates a time that is
> offset from
> UTC by 7 hours (and is approximately the same as the Pacific
> Daylight
> Time in the USA at that time of year)."

> Isn't it exactly the same?

> Perhaps it would be useful to draw this example out a little,
> for example to say that on another date such as 19 Oct, the
> time with a -07:00 offset would not be the same time as
> Pacific Daylight time, since that would no longer be in force
> - nor would it relate to Pacific 'non-Daylight' time, whatever
> that is called.

> I think it would be useful for people not so familiar with
> time theory to spell out (albeit in just a sentence or two)
> what is meant by 'time zone'.

Agreed.  It might also help to spell that example out a little
bit further, e.g., by saying "(and is the same as the Pacific
Daylight Time in the USA at that date in 2014 but would not be
the same as the Pacific Standard Time that would be applicable
in the same locations if the date were in January rather than
October)".  That at least hints that the switchover dates may
change by year and points out the the offset is not stable for a
location within the same year.   The text could then provide the
sentence or two of explanation that Richard suggests, using that
example.  One could make the example even stronger by picking a
date that would be in Daylight Time in 2014 but that would have
used Standard Time in, say, 1994.

I think the more we make the issues clear, the more likely this
proposal is to be accepted and used correctly.

> "future dates cannot be correctly represented by an offset
> alone"
> 
> But surely it's also risky to base them on time zones, since
> if it is,
> say, 5 years from now it could be that the rules will have
> been changed, eg. discontinuation of daylight savings?

But that is usually the intended behavior.   It is a close
relative to the time implied by the justification for time zones
on incremental times (e.g., "six months from the first midnight
in London after the date this is signed").  If one really wants
"5 years from now" to be independent of time zones, one is
probably better off using a more precise incremental time
statement, e.g., "noon, 1825 days from now" (or 1826 if the five
years intersected two leap years).   Again, some explanatory
text in the document would probably be helpful.  It could draw
on the above.   

FWIW, if the above suggests that the current text and rules
about specifying incremental times aren't quite precise enough,
that is a separate problem.    My astronomer colleagues from
years past claimed that the only incremental times that actually
worked accurately were expressed in seconds and fractions of
sections.  As soon as one started talking about calendars or
calendar units (like days), the only question was how fuzzy the
statements got because their being fuzzy was a given.  Then
again, they didn't like UTC either.

> Proposal 1 should state what happens if no tz attribute is
> used.

+1.  Probably as an explanation of what "floating time" (or,
referencing the astronomical comment above, vague incremental
time references) really mean.  There are lots of circumstances
in which "six weeks from now" or "next Monday" are really close
enough and we can actually cause problems by specifying or
implying more precision than is needed/intended.  For example,
depending on context 
   dateTime="2014-04-19"
may either refer to midnight in the appropriate location, to
some vague time during that day, or, if one encounters a culture
in which days start at sunset or moonrise, a variable time on
what a start-at-midnight culture would think of as the prior
day.   That, again, is mostly a separate problem, but times are
probably as complicated as languages and everything in
interconnected.

    john

p.s. The IETF is in the process of starting a WG to develop a
"time zone distribution protocol" that will provide for
distribution of those data.  It might be helpful for this spec
to make provision for a reference to that work when it
solidifies (and maybe to the IANA registry to which the data
have now been moved).

Received on Thursday, 14 August 2014 13:31:06 UTC