lidavidm commented on code in PR #35139:
URL: https://github.com/apache/arrow/pull/35139#discussion_r1168046225
##########
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:
> varCharVectorAccessor.getTimestamp(calendar) returns 2021-07-09
07:00:00.0. This does not make sense to me at all.
That's [midnight in Vancouver expressed as
GMT](https://www.wolframalpha.com/input?i=2021-07-09+07%3A00%3A00+GMT+in+Vancouver)
so it's consistent with the other case described above.
> conversion between time zones are incorrect.
It seems unintuitive, but at least consistent: it will take that date at
midnight in the given time zone, and express it in GMT, which seems to match
the docstring of java.sql.Date.
> Throw unsupported operation exception if vector does not have timezone set
and user has provided a timezone. The reason is that the returned timestamp
object cannot carry timezone info. Or return the timestamp as is to pretend it
is in the user supplied timezone?
That may also work, but I suppose if the user is explicitly passing a
Calendar, the current behavior is what they actually want? This is more a flaw
of the original Java date/time APIs in that Date itself doesn't carry the
timezone so the display value is weird.
--
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]
