Order relation on time

I'm forwarding a mail from Steve Hanna because it has not shown up in the 
email archive.

Satoshi Hada
IBM Tokyo Research Laboratory 
mailto:satoshih@jp.ibm.com
----- Forwarded by Satoshi Hada/Japan/IBM on 2003/08/14 09:13 -----


Steve Hanna <steve.hanna@sun.com>
2003/08/12 04:37
 
        To:     www-xml-schema-comments@w3.org
        cc:     Satoshi Hada/Japan/IBM@IBMJP
        Subject:        Order relation on time

 

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
answers.

Answer 1:

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).

Answer 2:

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.