Prasanth wrote:
> But when I use the latest 8.1-404 or even 8.2dev jdbc3 drivers I am
> observing a strange result.
>
> When I update a date in the resultset (say with 12/31/2005) and then
> call getDate it returns a date which is one day behind the value I have
> set (returns 12/30/2005).
> But it updates the database with the right date (12/31/2005). If I re
> fetch the same row then I can see the right value.
I couldn't reproduce this with your testcase. Possibly the effect you're
seeing is because you're not creating a strictly correct Date object:
> Calendar c = Calendar.getInstance();
This gives you a Calendar for the current system time.
> c.set(Calendar.MONTH, 1);
> c.set(Calendar.DATE, 2);
> c.set(Calendar.YEAR, 2005);
This resets the date to 2005/02/01, but leaves the time portion unchanged.
> Date d = new Date(c.getTimeInMillis());
This creates a java.sql.Date object that has a non-zero
hour/minute/second, which strictly speaking you're not meant to have.
The javadoc for java.sql.Date says:
>> To conform with the definition of SQL DATE, the millisecond values
>> wrapped by a java.sql.Date instance must be 'normalized' by setting the
>> hours, minutes, seconds, and milliseconds to zero in the particular time
>> zone with which the instance is associated.
Can you try a modified testcase that resets
hours/minutes/seconds/milliseconds on the calendar before getting the
millisecond value?
I'm not quite sure why this would cause the problem you're seeing,
though.. One other thing to try is to print the before/after values of
d.getTime(), which gives more exact information than Date.toString() does.
Also: what are the default timezones for your JVM and server?
-O
