- From: Richard Ishida <ishida@w3.org>
- Date: Wed, 13 Aug 2014 17:59:31 +0100
- To: www-international@w3.org
[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