# Order relation on time

From: by way of <steve.hanna@sun.com>
Date: Thu, 14 Aug 2003 06:50:23 -0700
Message-Id: <5.1.0.14.1.20030814065017.02868a68@localhost>
```Several readers have found that section 3.8 of XML Schema 1.0
Part 2 leaves some uncertainty as to the exact nature of the
order relation on time values. The text says:

Since the lexical representation allows an optional time
zone indicator, time values are partially ordered because
it may not be able to determine the order of two values
one of which has a time zone and the other does not. The
order relation on time values is the Order relation on
dateTime (section 3.2.7.3) using an arbitrary date. See
also Adding durations to dateTimes (appendix E). Pairs of
time values with or without time zone indicators are
totally ordered.

Here is an example that illustrates the potential for
misinterpretation. Two different answers are possible
to a given ordering question, depending on how the
specification is interpreted.

Question: Is 09:00:00+12:00 < 09:00:00-12:00?

It seems clear that the correct answer is no, since
section 3.2.8 of XML Schema 1.0 Part 2 says "time
represents an instant of time that recurs every day".
These two time values are 24 hours apart, so they
should be equal. But some interpretations of the
order relation for time values produces different

Step 1: Assign an arbitrary date to both time values:

Is dateTime 2002-02-16T09:00:00+12:00 < 2002-02-16T09:00:00-12:00?

Step 2: Apply the Order relation on dateTime:

Step 2A: Since both dateTimes contain a timezone,
normalize them to Z:

Is dateTime 2002-02-15T21:00:00Z < 2002-02-16T21:00:00Z?

Step 2B: Since both dateTimes contain a timezone,
compare P and Q field by field from the year field
down to the second field.

Since the day field of the first value (15) is less
than the day field of the second value (16), the answer
is true (that is, the first time value is less than the
second one).

Step 1: Normalize the time values to Z:

Is 21:00:00Z < 21:00:00Z?

Step 2: Assign an arbitrary date to both time values:

Is dateTime 2002-02-16T21:00:00Z < 2002-02-16T21:00:00Z?

Step 3: Apply the Order relation on dateTime:

Step 3A: Since both dateTimes contain a timezone,
normalize them to Z:

No change.

Step 3B: Since both dateTimes contain a timezone,
compare P and Q field by field from the year field
down to the second field.

Since all fields in the values are identical, the answer
is false (the first time value is not less than the
second one).

As stated above, I believe that the second answer (and
the second algorithm) is correct. It must be, otherwise
the definition of time values would be violated (because
these two time values which are clearly identical under
the definition of the type would not be equal under the
order relation).

However, the algorithm I described for calculating answer 2
above is not easily inferred from the specification. The
specification says "The order relation on time values is the
Order relation on dateTime (section 3.2.7.3) using an
arbitrary date." We believe that this means that for time
values with time zones, you must normalize the dates into a
single 24 hour period before applying the Order relation on
dateTime. An easy way to do this is to normalize the time
values to UTC and then assign an arbitrary year-month-day
value to them. But a more natural interpretation of the spec
would be to skip the normalization step and just assign the
year-month-day value. This will probably work just fine until
you encounter a situation like the one given above. We ran into
this while working on an XACML implementation (which uses the
XML Schema ordering for time values).

We suggest adding text to the XML Schema specification to
make it easier for implementors to understand the proper
interpretation of the spec. After the sentence that ends
with "using an arbitrary date", we would suggest adding
a sentence that says "Before assigning this arbitrary date,
time values with a time zone must be normalized to UTC."

Please let me know if you do not agree with our interpretation
of the specification. I do not subscribe to this email
list, so please include me on any responses.

Thanks,

Steve Hanna
Sun Microsystems, Inc.
```
• application/pkcs7-signature attachment: smime6.p7s
Received on Thursday, 14 August 2003 08:50:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:09:00 UTC