Github user paul-rogers commented on the issue:
https://github.com/apache/drill/pull/1184
@parthchandra, the point about the birthday is that is is one of those
dates that is implied relative to where you are. You celebrate it the same day
regardless of where you are in the world. Same with an order date. So, a key
problem is that, for dates, they are not relative to UTC, they are just dates.
They become relative to UTC only when a time and timezone is supplied.
As @jiang-wu explained, storing in UTC is fine when times are absolute
(date + time + tz). The problem is "2018-04-15" or even "2018-04-15 3 PM" is
not an absolute: it is local and cannot be stored as UTC unless we know the TZ.
Guessing that the TZ is that of the server really does not help, and actually
produces wrong results when client and server timezones differ.
That's why the data structures need to support the data model @jiang-wu
suggested:
* Date without TZ
* Time without a TZ
* Date/time without TZ, and
* Timestamp implied in UTC.
And, yes, it is because people abused the Java `Date` class that the Joda
time classes were invented. We just need to have Drill types that parallel the
Joda types. Granted, this is more than this fix can tackle, but the point
stands.
Agreed that the issue of how to handle JDBC/ODBC needs to be resolved. Can
we make up synthetic column names? Implicitly flatten the results so that
"context.date" will pick out the "date" element within "context". This will
allow JDBC to provide metadata and a reasonable type for each column, at the
cost of potentially creating a very wide row (if you have deeply nested maps.)
The "auto-flatten" option seems cleaner than any object-based format we make up.
A related solution is to fix `sqlline` so that it has a formatter other
than `toString()` as @jiang-wu suggested. We register a format class and
`sqlline` uses that to format, say, a Drill Map. That way we don't have to use
a JSON object so that its `toString()` produces nice output.
---
