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

The permitted operand types for value comparisons are summarized in the two tables that follow. Both operands must have the same type (as defined by a row in the table). Comparing two values whose types don't match (for example comparing an integer to a string) doesn't give you a result of
false
; it is a type error. This means the error may be reported either at compile time or at runtime, as discussed in Chapter 3. (As we'll see later,
xs:untypedAtomic
values are treated as strings.)

The first table is for
eq
and
ne
, and shows for each data type how the comparison is done.

Data type	Definition of eq
xs:string or xs:anyURI	An anyURI value is treated as a string. The two strings are compared using the default collation established in the static context for the expression. Collations are described in detail on page 459. In consequence, the results may be quite different in different environments, for example, in one context the strings Strasse and Straße may be equal; in another context, they may be unequal.
numeric	Any two numeric values can be compared ( xs:integer , xs:decimal , xs:float , or xs:double ). If they are of different types, one value is first promoted to the type of the other in the same way as for arithmetic operators (see page 571). They are then tested for numeric equality (this means, for example, that 1.00 and 01 will compare as equal). There are a couple of special cases with floating point numbers: positive and negative zero are considered equal to each other, but NaN (not a number) is not equal to any other number; in fact, it is not even equal to itself.
xs:boolean	Two xs:boolean values are equal if they are both true , or both false .
xs:dateTime	Two xs:dateTime values are equal if they represent the same instant in time. This means that if both include a timezone, they are adjusted so that they are in the same timezone (conventionally UTC, but any timezone would do). Although the XPath data model retains the original timezone attached to the value, it plays no part in the comparison: the two xs:dateTime values 2008-01-01 T02:00:00Z and 2007-12-31 T21:00:00-05:00 (2 a.m. in London and 9 p.m. the previous day in New York) are considered equal. If either or both of the values have no timezone, they are considered to represent times in the implicit timezone defined by the XPath evaluation context, as described in Chapter 7. If implicit timezones are set depending on the locale or preferences of the individual user, this means that two xs:dateTime values that appear equal for one user might appear not equal for another—but this can only happen in the situation where one of the values has an explicit timezone and the other does not.