[XML Schema] follows the
[ISO 8601]
standard for its lexical representation. Date and time values in ISO
8601 are field-based using the definitions above and can indicate (or
omit) the zone offset from UTC. A zone offset is not the same thing as a
time zone, and the difference can be important. XML Schema only
supports zone offset, but, confusingly, calls it time zone, see for
example section 3.2.8.1, lexical representation in
[XML Schema].
Although
ISO 8601 is expressed in terms of the Gregorian calendar, it can be
used to represent values in any calendar system. The presentation of
date and time values to end users using different calendar and
timekeeping systems is separate from the lexical representation.
What is a "zone offset"? A
zone offset
is the difference in hours and minutes between a particular time zone
and UTC. In ISO 8601, the particular zone offset can be indicated in a
date or time value. The zone offset can be
Z
for UTC or it can be a value "+" or "-" from UTC. For example, the value
08:00-08:00
represents 8:00 AM in a time zone 8 hours behind UTC, which is the equivalent of 16:00Z (8:00 plus eight hours). The value
08:00+08:00
represents the opposite increment, or midnight (08:00 minus eight hours).
What is a "time zone"? A
time zone
is an identifier for a specific location or region which translates
into a combination of rules for calculating the UTC offset. For example,
when a website maintaining a group calendar in the United States
schedules a recurring meeting for
08:00 Pacific Time
, it is referring to what is sometimes known as
wall time (so called because that is the time shown "
on the clock (or calendar) on the wall"). This is not equivalent to either
08:00-08:00
or
08:00-07:00
, because
Pacific Time
does not have a fixed offset from UTC; instead, the offset changes
during the course of the year. As mentioned before, XML Schema only
supports zone offsets, and it does not make the terminological
distinction between zone offset and time zone. So a wall time expressed
as an XML Schema
time
value, must choose which zone offset
to use. This may have the unintended effect of causing a scheduled event
to shift by an hour (or more) when wall time changes to or from
Daylight/Summer time.
To complicate matters, the rules for
computing when daylight savings takes effect may be somewhat complex and
may change from year to year or from location to location. In the
United States, the state of Indiana, for example, does not follow
daylight savings time, but this will change in April 2006. See:
http://www.mccsc.edu/time.html
for further information. The Northern and Southern hemispheres perform
Daylight/Summer Time adjustments during opposing times during the year
(corresponding to seasonal differences in the two hemispheres).
To capture these situations, a calendar system must use an
ID for the time zone. The most definitive reference for dealing with wall time is the TZ database (also known as the "Olson time zone database"
[tzinfo]),
which is used by systems such as various commercial UNIX operating
systems, Linux, Java, CLDR, ICU, and many other systems and libraries.
In the TZ database, "
Pacific Time" is denoted with the ID
America/Los_Angeles
. The TZ database also supplies aliases among different IDs; for example,
Asia/Ulan Bator
is equivalent to
Asia/Ulaanbaatar
. From these alias relations, a canonical identifier can be derived. The Common Locale Data Repository
[CLDR] can be used to provide a localized form for the IDs: see Appendix J in
[UAX 35].