Re: JDBC problem with dates and ANYELEMENT type - Mailing list pgsql-jdbc

From John Lister
Subject Re: JDBC problem with dates and ANYELEMENT type
Date
Msg-id 49F180D3.6070203@kickstone.com
Whole thread Raw
In response to Re: JDBC problem with dates and ANYELEMENT type  ("Peter" <peter@greatnowhere.com>)
List pgsql-jdbc
> What are the potential implications if I patch setDate() method in AbstractJdbc2Statement to pass OID.Date instead of
'unspecified'?Would that break anything else? We don’t use timestamps anywhere in the app yet, so I'm not really
worriedabout timezone being potentially screwed up. 
>
Reading the comments i would guess this would break a few things :(

But i didn't think postgresql supported dates with timezones (times yes
but not dates), so is the driver being overly cautious. Isn't passing it
as unspecified with a timezone, effectively passing a timestamp instead
of a date. Having the result be in the servers timezone might be
unexpected if the calendar parameter has a timezone, but isn't it the
correct behaviour?

Similarly looking at the binary patch posted previously, there is a
comment that dates aren't transmitted in binary because the unit tests
fail as they expect millisecond accuracy, surely in SQL a date has no
time component? If you require time as well shouldn't you be using
timestamp?


Just my thoughts and i guess it probably breaks a few users apps if this
were applied...

JOHN

pgsql-jdbc by date:

Previous
From: "Peter"
Date:
Subject: Re: JDBC problem with dates and ANYELEMENT type
Next
From: Kris Jurka
Date:
Subject: Re: Here's a fix to AbstractJdbc3Statement.getGeneratedKeys