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

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(at)netcetera(dot)ch> wrote:

> On 10.04.19 14:43, Mark Rotteveel 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.
>
> 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.
>
> Cheers
> Philippe
>
>
>