XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition (93 page)

This gives the problem of deciding whether a date that specifies a timezone (for example
1999-11-16-12:00
) comes before or after a date that doesn't specify a timezone (for example
1999-11-16
) when you want to perform comparison operations or sorting. If both dates have timezones, the answer is clear enough: the dates are sorted in order of their starting instants. And if neither has a timezone, you can assume that they relate to the same timezone. But if one has a timezone and the other doesn't, it's not obvious what the answer should be. XML Schema takes a rather purist view, saying that dates are
partially ordered
, which means that for some pairs of dates you don't know which one comes first. For an expression language like XPath, partial ordering is a nightmare: the system has to come up with some kind of answer. The answer chosen was that the system environment contains an implicit timezone that can be used as a default, and when dates with no timezone have to be compared or sorted, the system will assume that they refer to this implicit timezone. We look more closely at the implicit timezone when we examine the XPath evaluation context in Chapter 7.

The operations you can perform on a date include:

• Comparing and sorting dates
  
• Converting dates to and from strings
  
• Extracting the component parts of a date (year, month, day, timezone)
  
• Adding a duration to a date (or subtracting a duration) to get another date
  
• Determining the difference between two dates, as a duration
  
• Converting the value to an
  xs:dateTime
  (the result is the starting instant of the date)
  
• In XSLT only, formatting a date for human consumption (for example, as
  Wednesday 16th November
  )
  

Dates held using this type are always supposed to be Gregorian dates, even if they predate the introduction of the Gregorian calendar (which happened at different times in different countries). In principle, historic events are supposed to have their dates adjusted to represent them using the modern calendar.

Negative dates (BC dates) are supported, but they are a minor disaster area in XML Schema. According to XML Schema 1.0, the year zero is not allowed, and the year before 0001 is represented as –0001. However, shortly before XML Schema 1.0 was published, a new edition of ISO 8601 came out that stated that the year before 0001 should be represented as 0000. The draft XML Schema 1.1 specification has changed to match this, despite the fact that this affects the meaning of data in existing documents, and the results of queries. In practice, I would advise against using this type for historical dates. For most applications it's probably better to represent them using their original calendar.

xs:dateTime

The
xs:dateTime
type represents the combination of a date and time, that is, it represents an instant in time. The lexical representation is again based on ISO 8601, for example it might be
2008-04-12 T13:05:00Z
to represent five minutes past one in the afternoon of April 12, 2008, in the timezone Z (Z represents Coordinated Universal Time, abbreviated to UTC, and often still referred to by its older name of Greenwich Mean Time, or GMT).

The seconds part of an
xs:dateTime
can contain a fractional part. The number of significant digits that are retained is implementation-defined, but must be at least three.

As with
xs:date
, the complications with dates and times are all to do with timezones (if only the world could agree to synchronize its clocks, the problem would disappear). XML Schema takes the view that the value space of
xs:dateTime
represents instants in time, and that
2008-04-12 T13:05:00Z
and
2008-04-12 T08:05:00-05:00
are the same instant in time (five past one in London is five past eight in New York), and are therefore indistinguishable.