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.
Cheers
Philippe