I have a couple of questions, some of which might be bugs, but maybe it's just me misunderstanding something.
I understand that internally the TIME and DATE datatypes are identical. The only difference is in how the interface handles them. It seems a little strange to me that the only accepted format on input for both of them is "yyyy-MM-dd hh:mm:ss" and any part from right can be removed. That leads to a strange situation of accepting "yyyy-mm-dd" or even "yyyy" for TIME, but not "hh:mm:ss". Is there a reason for that? According to the docs for java.sql.Time, the date component should be always set to 1970-01-01 and not be accessed, but it seems to me that Phoenix's native JDBC driver does exactly that, because it exposes the original date. I guess this one is intentional. Even stranger is how the query server handles the types. It only accepts the formatted string or to_time/to_date function on it, but always outputs a number, which is the number of milliseconds since 00:00:00.000 for TIME and days since 1970-01-01 for DATE. So while you are forced to enter the full date/time on input, and it's also stored as such, you only get a part of it on output. Is the asymmetry intended? I'd have expected to have the same type on both input and output. The remote JDBC driver also crashes when fetching TIME/TIMESTAMP values (CALCITE-779), but that's definitely a bug. :) Another possible problem is that when parsing date/time values, the code raises java.lang.IllegalArgumentException instead of a "data error" java.sql.SQLException, so it has to be handled as "internal error" on the client, not a proper SQL exception. I guess the main question is what is the expected behavior for TIME/DATE/TIMESTAMP on all levels, internally in HBase, in the native JDBC driver and over the Avarica RPC? Lukas
