lidavidm commented on code in PR #35139:
URL: https://github.com/apache/arrow/pull/35139#discussion_r1168104521
##########
java/flight/flight-sql-jdbc-core/src/main/java/org/apache/arrow/driver/jdbc/utils/DateTimeUtils.java:
##########
@@ -47,7 +47,7 @@ public static long applyCalendarOffset(long milliseconds,
Calendar calendar) {
final TimeZone defaultTz = TimeZone.getDefault();
if (tz != defaultTz) {
- milliseconds -= tz.getOffset(milliseconds) -
defaultTz.getOffset(milliseconds);
+ milliseconds += tz.getOffset(milliseconds) -
defaultTz.getOffset(milliseconds);
Review Comment:
Thanks for bearing with me. The mess of date/time APIs here is confusing...
For Arrow: `timestamp[s, TZ]` appears equivalent to
`TIMESTAMP_WITH_LOCAL_TIMEZONE`. Arrow always stores the underlying value in
UTC. `timestamp[s]` appears to be `TIMESTAMP_WITHOUT_TIMEZONE`. Arrow does not
have an equivalent to `TIMESTAMP_WITH_TIMEZONE`.
So the question here is still the semantics of `getDate(int, Calendar)`. The
method looks ill-defined to me if `java.sql.Date` is not supposed to carry time
or timezone information in the first place...The API docs say "This method uses
the given calendar to construct an appropriate millisecond value for the date
if the underlying database does not store timezone information."
I do see things like this:
https://stackoverflow.com/questions/9202857/timezones-in-sql-date-vs-java-sql-date
> This means that when you work in UTC+1 and ask the database for a DATE a
compliant implementation does exactly what you've observed: return a
java.sql.Date with a milliseconds value that corresponds to the date in
question at 00:00:00 UTC+1 independently of how the data got to the database in
the first place.
So that also seems to match the existing behavior, by my reading.
I looked at Postgres's JDBC driver:
https://github.com/pgjdbc/pgjdbc/blob/3c3e5b62349c42d9d3dfe1fe0102776d4de8c353/pgjdbc/src/main/java/org/postgresql/jdbc/PgResultSet.java#L532
and
https://github.com/pgjdbc/pgjdbc/blob/3c3e5b62349c42d9d3dfe1fe0102776d4de8c353/pgjdbc/src/main/java/org/postgresql/jdbc/TimestampUtils.java#L639-L653
> Truncate date part so in given time zone the date would be formatted as
00:00
I think that also matches with the current behavior, as unintuitive as it is.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
