You are right that is not the JDBC driver that makes this happen. It is 
JDBC itself. java.sql.Timestamp is a subclass of java.util.Date but it 
returns the integral seconds when calling getTime(). It supports nano 
second precision with the getNanos() method.

The javadoc includes this note:
Note: This type is a composite of a java.util.Date and a separate 
nanoseconds value. Only integral seconds are stored in the 
java.util.Date component. The fractional seconds - the nanos - are 
separate. 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.  The Timestamp.equals(Object) method never returns  true 
when passed a value of type java.util.Date because the nanos component 
of a date is unknown. As a result, the Timestamp.equals(Object) method 
is not symmetric with respect to the java.util.Date.equals(Object) 
method.  Also, the hashcode method uses the underlying  java.util.Date 
implementation and therefore does not include nanos in its computation.

  Due to the differences between the Timestamp class and the 
java.util.Date class mentioned above, it is recommended that code not 
view Timestamp values generically as an instance of java.util.Date.  The 
inheritance relationship between Timestamp and java.util.Date really 
denotes implementation inheritance, and not type inheritance.

I hope this helped

/Fredrik Lindgren

Ed Bras wrote:

> Hellu,
> 
> I retrieve a datetime  field from the Ms SQL server. With a win sql client I
> see:
> 2001-10-03 19:33:10.257
> 
> When I print the field in an EJB (I use CMP) the millisecond part is zero
> !!!:
> Wed Oct 03 19:33:10 GMT+02:00 2001
> In milliseconds: 1002130390000
> 
> I had the same problem with the Postgres driver so I don't think it is the
> JDBC driver (Opta driver of i-net)
> 
> Has anyone any idea what is happening and how I can solve this ??
> Hope to get an answer, otherwise I have to convert the datetime fields in
> the database to a long to store it in milliseconds, which isn't very elegant
> I think !?
> 
> Eddie
> 
> 
> 
> 
> 
> 
> 



Reply via email to