Github user jiang-wu commented on the issue:

    https://github.com/apache/drill/pull/1184
  
    Yes.  There are at least two issues.  
    
    One is about how Drill represent Date, Time, Timestamp internally using a 
UTC based instant representation and fudges the timezone in order to make the 
none time zone fields looking right, that Paul outlined nicely above.  To 
really fix this, one would need to first define how Drill wishes to handle 
Date, Time, Timestamp: e.g. no time zone at all, time zone aware but not 
preserving, time zone aware and preserving, etc.  One can look at how databases 
handle time zones to get some inspirations.  This part is too ambitious for me 
to fix here.
    
    The second is to obtain a complex object value from JDBC interface.  Drill 
doesn't make a JSON object in order to send the data to a JDBC interface.  It 
looks like the JDBC interface is simple an alternative accessor to vector data 
being transmitted from the server side to the client side.  Once the vector 
data arrives on the client side, the JDBC layer builds a Map (or List) object 
by reading the values from the vectors.  The issue I found was that inside this 
process, date|time|timestamp values from their respective vector classes were 
all represented using the same Java class, hence losing its type information 
all together when the Java object is placed inside the Map|List.
    
    So a fix for this part is simple (in concept), just use different Java 
types.  Except, when making this change, the first issue popped up as one has 
to figure out how to make Date and Time out of UTC instant values, which are 
these fudged values from the existing logic


---

Reply via email to