Github user jiang-wu commented on the issue:
https://github.com/apache/drill/pull/1184
@parthchandra Just to clarify on the JDBC comment. What do you mean by
"Json representation"? Do you instead mean the "Local[Date|Time]" class
representation? There are no "Json" being returned from the JDBC layer. It
uses Java collections Map or List objects. Inside the Map | List, the change
in this pull request properly uses objects of different classes: Local
[Date|Time|DateTime] to represent the various date/time/timestamp values.
So far so good. Now, it is possible in the future, we may want to further
translate the Local [Date|Time|DateTime] objects inside the Map|List to
java.sql.[Date|Time|Timestamp] upon access. But to do that inside the
SqlAccessor, you would need to deep copy the Map|List and build another version
with the date|time translated into java.sql.date|time. That would seem like a
lot of work for little gain.
I would say let's hold off on that for now. A few databases seem to be
moving toward using non-timezone based representation in JDBC if the database
does not support timezones:
https://jdbc.postgresql.org/documentation/head/8-date-time.html It would make
sense to consider changing the class used after deciding on what to do with
Drill handling of timezones.
---
