RE: Comparison of time values

Ashok Malhotra wrote:
 > I suggest we use the above algorithm (start with normalized
 > time values, denormalize using the available timezone, add
 > same arbitrary date to both time values, normalize the resultant
 > dateTimes to Z and compare) and try and persuade Schema to adopt
 > this algorithm.

He also gave an example:

 > lexical values:  23:30:00-01:00 and 00:30:00Z
 > normalized values: 00:30:00Z and 00:30:00Z
 >
 > denormalize (or get back original values) using stored timezone:
 > 23:30:00-01:00 and 00:30:00Z
 >
 > add same date to both values to get dateTimes:
 > 2002-06-18T23:30:00-01:00 and 2002-06-18T00:30:00Z
 >
 > now normalize both dateTime values to timezone Z and we get
 > 2002-06-18T00:30:00Z and 2002-06-18T00:30:00Z
 >
 > now compare the two dateTime values and we get the first value
 > being later than the second.  This is the correct result.

Actually, this is not the correct result. The correct
result is that these two times are equal. Why? As I
pointed out in a recent email to www-xml-schema-comments@w3.org,
XML Schema Part 2 defines the time datatype this way (3.2.8):

   time represents an instant of time that recurs every day.

This is reinforced by section 3.2.8.2, which defines the
canonical representation for time by saying:

   Specifically, either the time zone must be omitted or,
   if present, the time zone must be Coordinated Universal
   Time (UTC) indicated by a "Z".

So if you convert the values 23:30:00-01:00 and 00:30:00Z
to canonical representation they are both 00:30:00Z.
How, then, can you argue that one is less than or greater
than the other?

The proper resolution of the anomalies pointed out by
you (and by Andrew Eisenberg and others) is that the
XML Schema time datatype has a very limited set of
values (24 hours of values with time zones and 24 hours
of values without time zones). No ordering of these values
will satisfy everyone's conception of ordering. But
the simple ordering provided (starting with 00:00:00Z
for times with time zones and 00:00:00 for values
without time zones) is perfectly fine for computers.

The OASIS XACML TC is planning to define a function named
time-in-range (or something similar) that takes three
time arguments (startRange, endRange, and value). It
will use the startRange and endRange to define a range
of time values (considering them to define an arc on
a 24 hour wheel). If the value argument falls within
this arc (including the endpoints of the arc), then
the function will return true. Otherwise, it will
return false. This function will make it easier for
end users to get the behavior they expect. Maybe you
will also find this function useful.

Thanks,

Steve Hanna
Sun Microsystems, Inc.