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

[forwarding Addison's reply]

Hi Richard,

Comments follow. Thanks for this.

Addison

 > -----Original Message-----
 > From: Richard Ishida [mailto:ishida@w3.org]
 > Sent: Wednesday, August 13, 2014 8:18 AM
 > To: Phillips, Addison; member-i18n-core@w3.org
 > Subject: Re: Reminder: Please review HTMLTimeZone proposal [I18N-ACTION-
 > 324]
 >
 > 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?

AP> It is from the point of view that the two have the same wall time at 
that instant. It isn't from the point of view that time zone provides 
some additional information. One of those bits of information is the 
time zone name. That is, the timestamp could be validly shown as:

"June 19, 2014, 7:10 PDT"

But also validly as:

"June 19, 2014, 7:10 MST" // America/Phoenix time zone, for example

 >
 > 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'.

AP> Agreed.
 >
 >
 > "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?
 >

AP> Not so much. The time zone is an *identifier* for a set of rules. 
Those rules include historical information. So "America/Los_Angeles" 
time zone knows about different time periods in which the summer time 
change was different (and how it was different). In addition, if the 
time zone changes its rules in the future (and one updates one's tzinfo 
database to match), the offset -07:00 is stuck, while 
America/Los_Angeles can "know" that the offset "now" (in the putative 
future without DST) is -08:00.
 >
 > Proposal 1 should state what happens if no tz attribute is used.

AP> Agreed.
 >
 >
 > ISO8601 -> ISO 8601

AP> Yep. Thanks.
 >
 >
 > Hope that helps,
 > RI
 >

Received on Wednesday, 13 August 2014 17:00:07 UTC