Github user paul-rogers commented on the issue:
https://github.com/apache/drill/pull/1184
Sorry, coming late. There seem to be two problems. The original "nested
column" issue is an artifact of the JDBC driver. In Drill, a Map (the thing
that contains your nested column) is just a nested tuple. But, JDBC does not
have the idea of a nested field, there is no way to ask, for, say "myMap.ts".
All you can ask for is "myMap" if it is a Map. The Drill JDBC driver has to
invent a value to return. It invents a Java map.
For JDBC, which does not support nested fields, you can project your field
up to the top level just by naming it in the select clause:
```
SELECT `context`.`date` as `context_date` ...
```
The second problem that this PR seems to address is how dates are stored.
Many tests have been changed to double-down on Drill's original sin: that
generic dates (2015-04-15, say) are represented a a timestamp in UTC. But, if
April 15 is your birthday, it is your birthday in all timezones. We don't say
your birthday (or order date, or newspaper issue date or...) is one day in, say
London and another day in Los Angeles.
Drill should have a "Date" type that is not associated with a timezone.
But, we don't so we get tied up in the "treat the local time zone as if it were
UTC" issue.
The original set of Drill types did have types to handle these, but they
didn't quite make it into the final version. Also, this issue has been
discussed (with some vigor) on the mailing list once or twice.
One flaw, that you seem to have spotted, is that if I read data on a server
in one TZ, then display it on a client in another TZ, the dates and times are
all messed up. The server reads dates in local TZ, then simply stores the ms
value in a date. The client thinks that date is UTC and adjusts it to its own
local TZ. All heck breaks loose. (Or something like that; the original test
case was over a year ago and I may have messed up the details...)
The ideal set of date/time types:
* Date: A date in an unspecified time zone, such as your birthday.
* Time: A time relative to midnight in an (unknown) Date, no association
with a TZ. For example, "we have lunch at 11:30 AM" applies regardless of TZ.
* Timestamp: an absolute time relative to UTC.
Then, functions can convert back and forth. Joda (and, in Java 8, the new
Date/time classes) work this way.
This means that the many tests that were modified to turn a generic date
into a timestamp are simply making the problem worse: we are saying that
2015-04-15 is midnight, April 15 in London, which is highly unexpected.
Bottom line: we've got two very difficult issues here: how to handle maps
in JDBC and how to fix Drill's date/time types.
---
