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