Re: order relation on dateTime

[I trust everyone realizes that Sandy's comments are about the 1.0
spec, not 1.1 .]

At 11:43 AM -0400 050505, Sandy Gao wrote:
>The ordering between two dateTimes P and Q is 
>defined by the following algorithm:
>
>A.Normalize P and Q. That is, if there is a 
>timezone present, but it is not Z, convert it to 
>Z using the addition operation defined in Adding 
>durations to dateTimes (§E)
>
>Thus 2000-03-04T23:00:00+03:00 normalizes to 2000-03-04T20:00:00Z
>B. If P and Q either both have a time zone or 
>both do not have a time zone, compare P and Q 
>field by field from the year field down to the 
>second field, and return a result as soon as it 
>can be determined. That is:
>1.        For each i in {year, month, day, hour, minute, second}
>a.        If P[i] and Q[i] are both not specified, continue to the next i
>b.        If P[i] is not specified and Q[i] is, 
>or vice versa, stop and return P <> Q
>c.        If P[i] < Q[i], stop and return P < Q
>d.        If P[i] > Q[i], stop and return P > Q
>2.        Stop and return P = Q
>
>C.Otherwise, if P contains a time zone and Q does not, compare as follows:
>1.        P < Q if P < (Q with time zone +14:00)
>2.        P > Q if P > (Q with time zone -14:00)
>3.        P <> Q otherwise, that is, if (Q with 
>time zone +14:00) < P < (Q with time zone -14:00)
>
>D. Otherwise, if P does not contain a time zone 
>and Q does, compare as follows:
>1.        P < Q if (P with time zone -14:00) < Q.
>2.        P > Q if (P with time zone +14:00) > Q.
>3.        P <> Q otherwise, that is, if (P with 
>time zone +14:00) < Q < (P with time zone -14:00)
>
>Problems:
>1. Step A is not necessary. Time zones are 
>already normalized when we convert lexical reps 
>to values. (There is no timezone property in the 
>value, only a boolean timezoned.)

True.  Totally redundant.

>2. How can the situation described in B.1.b ever happen?

It would mean that the two values are from different primitive d/t
datatypes.  Can't happen during schema processing.  We do maintain
that in every case if two values are from different primitive
datatypes they are incomparable, so this is just emphasizing that
convention.

>3. C.3. Shouldn't it be  Q with +14 <= P <= Q with -14
>4. Similarly in D.3, shouldn't it be  P with +14 <= Q <= P with -14

Yes.  Of course, if you accept the "otherwise" and ignore the almost-
correct explanation, you'll get it right.

I do believe we've got it right in 1.1 .  No reason these can't be
fixed for 1.0, if anyone still cares about 1.0 (probably they will
at least until 1.1 is final).
-- 
Dave Peterson
SGMLWorks!

davep@iit.edu