commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Todd V. Jonker" <t...@consciouscode.com>
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
functions:

    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*.)



Timestamp
On Tue, 17 Feb 2004 00:45:05 -0500, "Serge Knystautas"
<sergek@lokitech.com> 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 >> http://www.lokitech.com
> p. 301.656.5501
> e. sergek@lokitech.com


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message