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

The XSLT and XQuery working groups didn't feel it was acceptable that the original timezone information written in the source XML document should be simply thrown away. It didn't seem right, for example, that a transformation that copies a source document containing the value
2008-04-12 T08:05:00-05:00
should produce the value
2008-04-12 T13:05:00Z
in the result document. Although it's right to consider the two values as being equal (in the same way that 1 and 01 are equal) it seems that there is some information content in the timezone that the user probably wants to hold on to. So, after much agonizing and debate between the working groups, the XDM model defines a value space that retains the original timezone as well as the “instant in time”. This doesn't affect the test whether two
xs:dateTime
values are equal, but it does affect other operations, for example the operation of converting an
xs:dateTime
value to a string (which will reconstitute the original timezone).

Like
xs:date
values,
xs:dateTime
values don't need to specify a timezone, and XPath adopts the same solution: they are assumed to apply to an implicit timezone taken from the evaluation context.

The operations you can perform on an
xs:dateTime
include:

• Comparing and sorting dateTimes
  
• Converting dateTimes to and from strings
  
• Extracting the component parts of a dateTime (year, month, day, hour, minutes, seconds, timezone)
  
• Adding a duration to a dateTime (or subtracting a duration) to get another dateTime
  
• Determining the difference between two dateTimes, as a duration
  
• Extracting the date or time part separately
  
• Adjusting the timezone: that is, creating an equivalent dateTime with or without a timezone, or with a different timezone (see the
  adjust-dateTime-to-timezone()
  function on page 715)
  
• In XSLT only, formatting a dateTime for human consumption (for example, as
  Wednesday 16th November, 1.30p.m.
  )
  

xs:decimal

The
xs:decimal
type represents numbers that can be accurately expressed in decimal notation. This type is useful for values such as amounts of money, where the actual value space is discrete rather than continuous, and where the rounding errors that arise with binary formats such as
xs:double
and
xs:float
are undesirable.

In a user-defined subtype of
xs:decimal
, the values can be restricted in terms of the total number of allowed digits, and the number of digits allowed after the decimal point. If the built-in type
xs:decimal
is used without restriction, the number of digits allowed must be at least 18, though it can be greater than this if the implementation chooses. Some implementations may use an unlimited-precision representation (Saxon does, for example).

Any numeric literal written with a decimal point in XPath 2.0 (but without using exponential notation) represents an
xs:decimal
value, for example the literal
3.50
. Note that this represents exactly the same
xs:decimal
value as the literal
3.5
: in general, trailing zeros after the decimal point will be lost when
xs:decimal
values are manipulated, which can be a bit awkward when you are handling amounts of money. For example, the result of
2.44 + 2.56
is displayed as
5
. XSLT has a function
format-number()
that allows you to control the way values are formatted; for example, you can use a picture of
0.00
to ensure that there are always two digits after the decimal point. But there is no equivalent to this in XPath or XQuery.