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.
Mark -- Mark Rotteveel
The whole time, timestamp, timezone thing was not well thought out and is the bane of all driver implementers existence...
