Github user parthchandra commented on the issue:
https://github.com/apache/drill/pull/1184
> 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.
If it is your birthday in California, it may already be the day after your
birthday in Japan. :)
IMO, Representing dates, times, and timestamp's as UTC is not the problem.
It is, in fact, perfectly correct (since UTC is the timezone). Converting a
date|time|timestamp without a timezone to/from UTC, is the problem. The problem
is made worse by java.util and JDBC APIs. java.time gets it right though.
However, as Jiang-wu points out, that still does not address the mismatch
between Joda/Java8 representation and JDBC. It also does not address his
original problem, the issue of how to represent a complex type in JDBC; just
return an Object, it says, which is no help at all . It is even worse for ODBC
which (last I checked) did not even have an API to return an Object type (which
is why in ODBC we return a JSON string representation).
For Jiang-wu's use case, since the string representation is not enough, we
might look at returning a java.sql.Struct [1] type for Maps and java.sql.Array
[2] types.
[1] https://docs.oracle.com/javase/7/docs/api/java/sql/Struct.html
[2] https://docs.oracle.com/javase/7/docs/api/java/sql/Array.html
---
