[Mulgara-dev] [Mulgara-svn] r1183 - trunk/src/jar/store-stringpool/java/org/mulgara/store/stringpool/xa

[Paul Gearon]

I'd normally try to snip out parts of the email that I specifically
want to respond to, but in this case I think it's better to leave it
all. See remarks below....

>>      public int compare(ByteBuffer d1, int st1, ByteBuffer d2, int st2) {
>> -      return AbstractSPObject.compare(d1.getLong(), d2.getLong());
>> +      int c = AbstractSPObject.compare(d1.getLong(), d2.getLong());
>> +      // if the times are the same, then differentiate by timezone
>> +      if (c == 0) c = AbstractSPObject.compare(d1.getInt(), d2.getInt());
>> +      return c;
>>      }
>
> I'm not sure this is quite correct: according to the xml-schema spec
> part 2 (datatypes) all dates with a timezone are totally ordered (and
> same for all dates without a timezone) and comparison is done on the
> normalized (to UTC) date. While it doesn't talk about equality
> explicitly, I'm assuming that within a totally ordered set we can
> assume "not(A < B) and not(B < A) => A == B".
>
> Since the dates are stored in UTC already, this means that the
> timezone compare above should return true if either both have a
> timezone (irrespective of what that timezone is) or both don't have
> a timezone;
>
> I'm not sure about comparing with-timezone to without-timezone,
> though - since that's only partially ordered we can't make the above
> implication, so I guess they always compare as not-equal.
>
> OTOH, the SPComparator.compare seems to assume a total ordering, i.e.
> doesn't have a way to say "I can't compare these two values". That's
> not a problem for equality checking per se, but does present a problem
> for anything that tries to order things.

There are 2 issues here.

First, in terms of comparing dates, differing dates will always be
ordered correctly. It only goes on to compare the timezone values if
the dates are identical. So general ordering will be correct. The
issue is that I'm now ordering identical dates with differing
timezones.

Second, this is the SPComparator. This comparator is not used for
value comparisons, but rather, it is used for locating information
within the tree index. If it returns 0 for equal values with different
timezones, then that means that a search on one can return the other.
That behavior means that the tree can only store the first one it is
given, and will refuse the second value, since it believes this date
is already in there. By having the SPComparator return a non-zero
value when the timezones are different, we can store both values.

If you need value comparisons, then this is done with the
SPDateImpl.compareTo(SPObject) method. This method continues to ignore
timezones, as you say.

Paul