Re: JDBC and timetz again

Поиск
Список
Период
Сортировка
От Mark Rotteveel
Тема Re: JDBC and timetz again
Дата
Msg-id 68340b56fd7d35945d869c94866cbc1d@lawinegevaar.nl
обсуждение исходный текст
Ответ на Re: JDBC and timetz again  (Thomas Kellerer <shammat@gmx.net>)
Список pgsql-jdbc
On 2020-04-21 12:28, Thomas Kellerer wrote:
> Mark Rotteveel schrieb am 21.04.2020 um 11:02:
>> Note that JDBC itself doesn't define support for java.sql.Time (or
>> java.time.LocalTime) for time with time zone types (instead it maps
>> to java.time.OffsetTime).
> I know that JDBC doesn't support that (and I mentioned the thread were
> that was discussed previously) but I would expect the driver to at
> least return a value that is correct.
> 
> The interesting thing is, that if I use ResultSet.getString() on that
> column I do get the correct "value", e.g. the following:
> 
>   ResultSet rs = stmt.executeQuery("select current_time");
>   rs.next();
>   System.out.println("getString: " + rs.getString(1));
>   System.out.println("getTime:   " + rs.getTime(1));
> 
> will print (when run at 12:26:08):
> 
>   getString: 12:26:08.275455+02
>   getTime:   11:26:08
> 
> So at some point the driver does get the correct time, but the
> conversion to a java.sql.Time seems to lose one hour somewhere.

To be clear, I haven't checked exactly what the PostgreSQL JDBC driver 
does, but I think that it has to do with this part of the awkward 
definition of `java.sql.Time`[1]:

"""
The date components should be set to the "zero epoch" value of January 
1, 1970 and should not be accessed.
"""

Take 12:26:08 in Europe/Berlin, today (with DST) that is 10:26:08 UTC, 
take 10:26:08 UTC on 1970-01-01 and in Europe/Berlin it's 11:26:08.

[1]: 
https://docs.oracle.com/en/java/javase/11/docs/api/java.sql/java/sql/Time.html



В списке pgsql-jdbc по дате отправления:

Предыдущее
От: Thomas Kellerer
Дата:
Сообщение: Re: JDBC and timetz again
Следующее
От: ItaiFonio
Дата:
Сообщение: [pgjdbc/pgjdbc] 5e97af: docs: remove Supported Versions fromdownloads pag...