This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 17857 - i18n-ISSUE-92: time zone vs. time zone offset
Summary: i18n-ISSUE-92: time zone vs. time zone offset
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
Depends on:
Reported: 2012-07-18 07:04 UTC by contributor
Modified: 2013-04-15 22:59 UTC (History)
5 users (show)

See Also:


Description contributor 2012-07-18 07:04:42 UTC
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 <>

 #0   Addison Phillips                                2012-05-07 17:17:26 +0000 
-------------------------------------------------------------------------------- Global dates and times

This section gives a number of examples that equate time zone offset with an actual time zone. For example:

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?
Comment 1 Ian 'Hixie' Hickson 2012-07-20 04:03:43 UTC
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.
Comment 2 Ian 'Hixie' Hickson 2012-10-04 02:33:00 UTC
Comment 3 Ian 'Hixie' Hickson 2012-12-30 05:37:29 UTC
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).
Comment 4 Addison Phillips 2012-12-30 06:31:20 UTC
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.
Comment 5 Ian 'Hixie' Hickson 2012-12-30 19:29:23 UTC
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.
Comment 6 Addison Phillips 2012-12-30 19:35:22 UTC
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:

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.
Comment 7 Ian 'Hixie' Hickson 2012-12-31 04:12:27 UTC
That database talks about geographical locations, just as I was suggesting we put in the spec.
Comment 8 Ian 'Hixie' Hickson 2013-03-06 20:23:46 UTC
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 as the suggested list of geographic locations to use.
Comment 9 contributor 2013-03-06 20:23:55 UTC
Checked in as WHATWG revision r7733.
Check-in comment: Add more commentary on time zones.
Comment 10 Addison Phillips 2013-03-06 21:03:19 UTC
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 ( as an example of [time zone rules].
Comment 11 Ian 'Hixie' Hickson 2013-04-15 22:59:29 UTC
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...)
Comment 12 contributor 2013-04-15 22:59:54 UTC
Checked in as WHATWG revision r7840.
Check-in comment: More info about time zones.