commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Todd V. Jonker" <>
Subject Re: DateUtils.equals(d1, d2)
Date Tue, 17 Feb 2004 15:37:32 GMT
Serge, good point about Timestamp.getTime(), I missed that.

However, the spec changed twice between JDKs 1.3.1 and 1.4.2.

Timestamp 1.3.1 doesn't override util.Date.getTime() and states:

"The getTime method will return only integral seconds. If a time value
that includes the fractional seconds is desired, you must convert nanos
to milliseconds (nanos/1000000) and add this to the getTime value."

"Also, the hashcode method uses the underlying java.util.Data
implementation and therefore does not include nanos in its computation."
Timestamp 1.4.1 provides the same first blurb above, but this is
contradicted by the description of the now-overridden getTime(). I
suspect that the class description is incorrect.
Timestamp 1.4.2 is consistent between both sections, as you point out.

Given the fact that [lang] needs to work on all JDKs, this will be quite
tricky to implement correctly.  And again I assert that attempting
comparisons of this type are a Really Bad Idea.

Hibernate can also map Timestamp instead of Date.  But if you only use
date on the app-side of Hibernate, Date comparisons have always worked
for me in my unit testing.  If you go straight to the database and nab a
Timestamp, then you have conversion issues of course, so I'm guessing
that's what you're doing.

Perhaps a less controversial solution would be a set of conversion

    Date toDate(Timestamp timestamp);
    Timestamp toTimestamp(Date date);

The conversion would still be tricky to get correct on all JVMs, but at
least it would avoid a comparison API with questionable semantics.

(And yes, the Oracle driver we're stuck with in production is a buggy
mess regarding timestamps and dates, *sigh*.)

On Tue, 17 Feb 2004 00:45:05 -0500, "Serge Knystautas"
<> said:
> Todd V. Jonker wrote:
> > Serge, I'm not sure that your proposed method will do what you want.
> > 
> > You can't compare the results of java.util.Date.getTime() and
> > java.sql.Timestamp.getTime() because the latter is only precise to the
> > second, not the millisecond.  Likewise, java.sql.Date.getTime() is only
> > precise to the second.
> I understand java.sql.Timestamp is a bit screwy, but if you read the 
> javadoc for getTime() method, it says, "Returns the number of 
> milliseconds since January 1, 1970, 00:00:00 GMT represented by this 
> Timestamp object."  So it should return milliseconds even if it is 
> structurally holding something different underneath.
> Regardless, it would help my situation... I'm using a db mapping layer 
> (hibernate) and it sets a java.util.Date object from the ResultSet.  My 
> app code then prints to user, parses the data back, and I set the Date. 
>   I want to check whether the value is changed, and I'm actually only 
> expecting resolution to date usually, sometimes to minute.
> > Just my two cents from painful experience...
> You may want to revisit the JDBC drivers that put you through this.  The 
> ones I use now all do getTime() as milliseconds, and some of them used 
> to do just seconds as the class-level javadoc implies.  Maybe this was 
> clarified in one of the more recent JVMs, dunno.
> -- 
> Serge Knystautas
> President
> Lokitech >> software . strategy . design >>
> p. 301.656.5501
> e.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message