Not everyone agrees with WITH TIMEZONE qnd it doesn't help that the server does not store the timezone
On Wed, Apr 17, 2019, 8:35 AM Philippe Marschall, <pm@netcetera.ch> wrote:
On 10.04.19 14:43, Mark Rotteveel wrote: > On 9-4-2019 13:20, pm@netcetera.ch wrote: >> On 06.04.19 19:40, Thomas Kellerer wrote: >>> I think the driver should then support getObject(1, >>> OffsetTime.class), shouldn't it? >> >> It was originally not implemented out of laziness, somewhat justified >> by the fact that the documentation recommends against using the type >> saying it's only present because of legacy and standards compliance >> reasons. From a functional point of view there is nothing wrong with >> implementing it. Again, in practice it's hard to find a use for the type. >> >> Yes the type should be Types.TIME_WITH_TIMEZONE. However in #695 [2] >> it was decided that following the JDBC specification would break >> frameworks and it would be better to instead go against the JDBC >> specification and instead having each framework implement driver >> specific hacks. > > This decision will still mean that frameworks will have to implement > driver-specific hacks though: That is those tools or frameworks that do > follow the guidance of the JDBC 4.2 or higher specification and expect > to be able to obtain the LocalXXX types here. > > If you declare that a column is Types.TIME(STAMP), then you should also > be able to return java.time.LocalTime, java.time.LocalDateTime (and of > course java.sql.Time/java.sql.Timestamp). > > Declaring Types.TIME(STAMP), but not supporting java.time.LocalXXX is in > my opinion a worse 'violation' of the JDBC specification compared to > declaring Types.TIME(STAMP) instead of Types.TIME(STAMP)_WITH_TIMEZONE. > By saying you are Types.TIMESTAMP, you implicitly promise to deliver the > type conversions defined in Appendix B of JDBC 4.3 (B.4/B.5). Supporting > java.time.OffsetDateTime / java.time.OffsetTime on Types.TIME(STAMP) is > then just a non-standard extension. > > That of course leaves the problem of ambiguity what local means in the > context of a type with time zone information.
I agree with you. We should report _WITH_TIMEZONE as the type and support Offset* types for the tz database types. For the non tz types we support the Local* types and report Types accordingly.
This is a case were deviating from the standard with well defined semantics just leads to more and more issues down the road.
