Just checking instanceof Timestamp and JVM version concerns me, because
it seems to assume that the driver is doing the right thing.  I also have
no idea how this really works for different drivers, thus my queasiness.

I like your idea of calling getTime() and rounding to the second.  That
should work in all cases.

However, if either d1 or d2 do have nanosecond precision, so you really
want to ignore that information?  As a programmer I'd want to belive that

  DateUtils.equals(timestamp1, timestamp2) ==
  timestamp1.equals(timestamp2)

for non-null values.  The code below can't promise that.

How about always comparing to nanosecond precision, and just assume that
util.Date and sql.Date have those bits zero?  Essentially convert Dates
to Timestamp before comparing.  That might actually make this thing
semantically sound.  :-)


On Tue, 17 Feb 2004 10:59:24 -0500, "Serge Knystautas"
<[EMAIL PROTECTED]> said:
> DateUtils.equals(Date d1, Date d2) {
>    if (d1 == null || d2 == null) {
>      return d1 == d2;
>    }
>    boolean screwyTimestamp = d1 instanceof Timestamp
>                           || d2 instanceof Timestamp;
>    if (SystemUtils.isJavaVersionAtLeast(1.4) or !screwyTimestamp) {
>      return d1.getTime() == d2.getTime();
>    } else {
>      long ms1 = d1.getTime();
>      if (d1 instanceof Timestamp) {
>        ms1 += ((Timestamp) d1).getNanos() / 1000;
>      }
>      if (d2 instanceof Timestamp) {
>        ms2 += ((Timestamp) d2).getNanos() / 1000;
>      }
>      return ms1 == ms2;
>    }
> }
>
> This may not work if you've got an Oracle driver that runs in JDK 1.3 
> and so follows that convention, but then you're running in JDK 1.4.  I 
> don't know how that is handled.
> 
> If that's the case, we can skip the JVM detection, and instead if it's a 
> timestamp round getTime() to the nearest second and then add back in 
> nanos/1000.  This way regardless of what JVM you're in or driver you're 
> using, you should always get the correct number of milliseconds.
> 
> -- 
> Serge Knystautas
> President
> Lokitech >> software . strategy . design >> http://www.lokitech.com
> p. 301.656.5501
> e. [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to