# Re: Error in the spec (#3)

• From: Kohsuke KAWAGUCHI <k-kawa@bigfoot.com>
• Date: Wed, 21 Feb 2001 10:34:29 -0800
• To: "Ashok Malhotra" <petsa@us.ibm.com>
• Message-Id: <20010221100702.B70A.K-KAWA@bigfoot.com>
```I really appreciate your reply.

> Would you prefer if we had separate rules for < and = ?
> This would just make the algorithm longer.  I see

I'm sorry for my obscure writing. Let met put it in this way.

My point is, the spec should define "<" relation, rather than "<="
relation.

-------------
Common sense tells us that "a<=b iff a<b or a=b". I'd like this
proposition to apply to dateTime type, too.    (1)
-------------

I assume you agree with the above statement.

The current definition of order-relation of dateTime type (where one has
time zone and the other doesn't) is the following:

> P <= Q if P <= (Q with time zone -14)          (2)
> P >= Q if P >= (Q with time zone +14)
> P <> Q otherwise, that is, if (Q with time zone -14) < P < (Q with time zone +14)

The aforementioned common sense implies that " P<=Q iff P<Q or P=Q".
In this case, since one has time zone and the other not, P is never
equal to Q. Therefore, "P<=Q iff P<Q".

This yields a little bit strange definition

P<Q   if  P<=(Q with time zone-14)              (3)

Thus "2001-01-01T14:00:00 > 2001-01-01T00:00Z".
I doubt if this is the intention of WG.

If this is the intention of WG, then the spec should define '<' in this
way rather than defining '<=', because '<' is the fundamental relation
and '<=' is not.  The spec mentioned this in section 2.4.1.2.

And you may not define '<=', because the equation (1) is enough.

Note that

P<Q   if P<(Q with time zone-14)             (4)

Equations (1),(3), and (4)  (a common sense, the current definition, and
a natural definition for '<') are inconsistent, although every two of
them is consistent.

I suspect the schema WG doesn't aware that these three are inconsistent.

regards,
----------------------
K.Kawaguchi
E-Mail: k-kawa@bigfoot.com
```

Received on Wednesday, 21 February 2001 13:34:31 UTC