On 06.04.19 19:40, Thomas Kellerer wrote:
> Mark Rotteveel schrieb am 06.04.2019 um 10:15:
>>> Retrieving the value of a timetz column fails when using getObject(,
>>> LocalTime.class)
>>>
>>> I am not sure if this is the same as:
>>> https://github.com/pgjdbc/pgjdbc/issues/1048
>>> If it's not the same root cause, should I create an issue?
>>>
>>> Using "select localtime" instead, works just fine
>
>> For reference, the JDBC specification does not specify support
>> java.time.LocalXXX types on WITH TIME ZONE types.
>>
>> Especially because it is rather ambiguous what local would mean: would
>> it mean local in the default JVM time zone, local at the original zone
>> or local at UTC?
>
> Makes sense.
>
> However, the column is reported as Types.TIME and not
> Types.TIME_WITH_TIMEZONE, that's why I stumbled over it.
>
> 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.
[1]
https://www.postgresql.org/docs/current/datatype-datetime.html#DATATYPE-TIMEZONES
[2] https://github.com/pgjdbc/pgjdbc/pull/695
Cheers
Philippe
