> 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
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?
In response to
pgsql-jdbc by date
|Next:||From: Tom Lane||Date: 2006-01-16 22:40:06|
|Subject: Re: reading an oidvector field error |
|Previous:||From: Prasanth||Date: 2006-01-16 22:13:10|
|Subject: getDate after call to updateDate|