Re: JDBC problem with dates and ANYELEMENT type

Поиск
Список
Период
Сортировка
От John Lister
Тема Re: JDBC problem with dates and ANYELEMENT type
Дата
Msg-id 49F180D3.6070203@kickstone.com
обсуждение исходный текст
Ответ на Re: JDBC problem with dates and ANYELEMENT type  ("Peter" <peter@greatnowhere.com>)
Список 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 по дате отправления:

Предыдущее
От: "Peter"
Дата:
Сообщение: Re: JDBC problem with dates and ANYELEMENT type
Следующее
От: Kris Jurka
Дата:
Сообщение: Re: Here's a fix to AbstractJdbc3Statement.getGeneratedKeys