Will Noble created CALCITE-5492:
-----------------------------------
Summary: Adjusting dates based on time zone doesn't always make
sense
Key: CALCITE-5492
URL: https://issues.apache.org/jira/browse/CALCITE-5492
Project: Calcite
Issue Type: Improvement
Components: avatica
Reporter: Will Noble
The JDBC API allows you to provide a {{Calendar}} argument to
[ResultSet.getDate()|https://docs.oracle.com/javase/7/docs/api/java/sql/ResultSet.html#getDate(int,%20java.util.Calendar)]
"to use in constructing the date" and Avatica currently uses it to adjust the
millisecond value of the {{java.sql.Date}} object that comes out of a result
set according to the time zone of the calendar, similar to how it adjust
timestamps and time-of-day values.
This might make sense if Calcite always represented date objects with
millisecond precision, but since it often represents them as an integer number
of days since 1970-01-01, adjusting based on time zone does not make sense in
general. This has become an issue in the fix for
[CALCITE-5488|https://issues.apache.org/jira/browse/CALCITE-5488] because date
values may have to be "un-adjusted", but information may have already been lost
due to truncating division to convert milliseconds to days.
I'm not yet sure what the best way to proceed might be, but I'm wondering what
the intended semantics here are. Is a date meant to have millisecond resolution
(in which case representing it as an integer number of days does not make
sense), or is it meant to have only day resolution (in which case applying a
time zone does not make sense)?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
