[
https://issues.apache.org/jira/browse/CALCITE-5492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Noble reassigned CALCITE-5492:
-----------------------------------
Assignee: Will Noble
> 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
> Assignee: Will Noble
> Priority: Major
>
> 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)
