- From: John C Klensin <john+w3c@jck.com>
- Date: Thu, 14 Aug 2014 09:30:37 -0400
- To: Richard Ishida <ishida@w3.org>, "Phillips, Addison" <addison@lab126.com>, www International <www-international@w3.org>
--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