This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This was was cloned from bug 16962 as part of operation convergence. Originally filed: 2012-05-07 17:17:00 +0000 Original reporter: Addison Phillips <addison@lab126.com> ================================================================================ #0 Addison Phillips 2012-05-07 17:17:26 +0000 -------------------------------------------------------------------------------- 2.5.5.7 Global dates and times http://dev.w3.org/html5/spec/single-page.html#global-dates-and-times This section gives a number of examples that equate time zone offset with an actual time zone. For example: -- "1979-10-14T12:00:00.001-04:00" One millisecond after noon on October 14th 1979, in the time zone in use on the east coast of the USA during daylight saving time. -- It should be made clear that a zone offset is not the same thing as a time zone. Mention should be made of the need for separate time zone information when working with real date and time values in use cases that depend on it (see our note "Working with Time Zones") Norbert commented: The issue really is: why don't we use IANA time zone names to identify time zones? "-04:00" could be "the time zone in use on the east coast of the USA during daylight saving time", but it could also be one of many other time zones. ================================================================================ #1 Ian 'Hixie' Hickson 2012-05-10 18:02:26 +0000 -------------------------------------------------------------------------------- The example quoted is accurate -- the time it refers to is indeed on the east coast of the USA, and not another time zone that happens to have the offset -04:00. There's no way to tell that from the time itself, but that's just a limitation of the ISO format. Are there any cases where the terms are confused? I thought I had been careful about the way the terms were used. ================================================================================ #2 Norbert Lindenberg 2012-05-16 02:07:04 +0000 -------------------------------------------------------------------------------- How do you know "the time it refers to is indeed on the east coast of the USA" and not in Venezuela? ================================================================================
Because I wrote the example and know to what event the example refers, and the example happened on the east coast. And the spec says so. There's no way to know this just from the date, but as mentioned in the #1 above, that's just a limitation of the ISO format.
Consider: https://github.com/w3c/html/commit/c7be97aaa6b33436758d1d5290bf7d384488e993
Might be worth adding something in the <time> section under "valid time-zone offset string" and under "valid global date and time string", and in the input section in the type=datetime subsection (maybe in the example that's already there), basically saying that if the time is of a recurring event that is at a fixed local time rather than at a fixed global time, using a timezone-less time and specifying the physical location is a better idea than using time zones, since time zones at a specific location change with daylight savings (and sometimes for other reasons).
There is a difference between a time zone and a zone offset: a point the I18N wg has been at pains to point out in our bugs. A time zone doesn't have the issues you cite. They include the necessary information about DST/summer time.
Even "time zone" doesn't have enough information. What time zone is Libya in? What time zone was it in last year? What time zone was it in in the 1980s? If you have a time that you intend to be interpreted locally reliably in the face of government decrees, you don't want either a time zone offset or a time zone, you want a geographical location. Anyway, virtually nobody uses the term "time zone" correctly. I try to use it correctly in the HTML spec, though I'm sure I've made mistakes (and I certainly use the terms loosely in bugs and e-mail), but I'm not going to try to explain things in the spec in a way that requires readers to understand the difference between an offset and a zone. The message would not get across.
When I (and others in the I18N WG) use the word "time zone" I mean explicitly the value/id associated with rules (current and historical), as defined by the IANA time zone database: http://www.iana.org/time-zones I use the term "zone offset" to refer to the UTC +/- values seen on e.g. ISO 8601 date/time values. This has all of the problems you describe. And the I18N WG is not asking you to fully explain all of this. We are asking you to provide links to a reference which does and a note pointing out merely that a zone offset is insufficient for almost anything other than a timestamp.
That database talks about geographical locations, just as I was suggesting we put in the spec.
I've added additional explanatory material regarding when it's appropriate to use time zone offsets and when it's appropriate to use geographical locations. Leaving open to consider referencing http://www.iana.org/time-zones as the suggested list of geographic locations to use.
Checked in as WHATWG revision r7733. Check-in comment: Add more commentary on time zones. http://html5.org/tools/web-apps-tracker?from=7732&to=7733
Thanks for these changes. Looks good. One item to point out. You mention "geographic location" in a number of places, such as: -- For events where the precise time varies by the local time zone offset of a specific geographic location, a <span>valid local date and time string</span> combined with that geographic location is likely more useful -- I would suggest actually mentioning time zones. Perhaps as: -- ... combined with the [time zone rules] associated with that geographic location is likely more useful -- You might also want to include an informative link to IETF BCP 175 (http://tools.ietf.org/html/rfc6557) as an example of [time zone rules].
Ok, tried adding something like that. (Not sure what to do about the fact that there's a dozen places in the spec where someone might look where they need to be told this stuff, given that I don't want to paste the same five-paragraph blob everywhere since that makes the spec unreadable for everyone else. I've basically tried to dot the info around so hopefully we won't overload everyone and people who actually need it will at least learn they have to learn more...)
Checked in as WHATWG revision r7840. Check-in comment: More info about time zones. http://html5.org/tools/web-apps-tracker?from=7839&to=7840