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