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

Life is hard, and then you die ronald at innovation.ch
Wed Aug 27 06:11:54 UTC 2008


On Tue, Aug 26, 2008 at 04:32:21PM -0700, pag at mulgara.org wrote:
> Author: pag
> Date: 2008-08-26 16:32:20 -0700 (Tue, 26 Aug 2008)
> New Revision: 1183
> 
> Modified:
>    trunk/src/jar/store-stringpool/java/org/mulgara/store/stringpool/xa/SPDateImpl.java
> Log:
> Dates are now inserted into the index using their timezone information as well, meaning that equivalent dates with different representations will show up as different entries. This should close #138
> 
> Modified: trunk/src/jar/store-stringpool/java/org/mulgara/store/stringpool/xa/SPDateImpl.java
> ===================================================================
> --- trunk/src/jar/store-stringpool/java/org/mulgara/store/stringpool/xa/SPDateImpl.java	2008-08-26 20:30:01 UTC (rev 1182)
> +++ trunk/src/jar/store-stringpool/java/org/mulgara/store/stringpool/xa/SPDateImpl.java	2008-08-26 23:32:20 UTC (rev 1183)
> @@ -225,7 +225,10 @@
>      }
>  
>      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.

Or am I missing something?


  Cheers,

  Ronald




More information about the Mulgara-dev mailing list