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 по дате отправления: