Adjusting dates based on time zone doesn't always make sense

The JDBC API allows you to provide a Calendar argument to ResultSet.getDate() "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 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)?