Re: ResultSet.getObject(..., LocalTime.class) not working with Postgres timetz type

On Wed, 10 Apr 2019 at 08:43, Mark Rotteveel <mark(at)lawinegevaar(dot)nl> wrote:

> On 9-4-2019 13:20, pm(at)netcetera(dot)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...

Dave Cramer

davec(at)postgresintl(dot)com
www.postgresintl.com