scruz-denodo commented on code in PR #43149:
URL: https://github.com/apache/arrow/pull/43149#discussion_r1688284132
##########
java/flight/flight-sql-jdbc-core/src/main/java/org/apache/arrow/driver/jdbc/accessor/impl/calendar/ArrowFlightJdbcDateVectorAccessor.java:
##########
@@ -108,11 +104,36 @@ private void fillHolder() {
@Override
public Timestamp getTimestamp(Calendar calendar) {
- Date date = getDate(calendar);
- if (date == null) {
+ final LocalDateTime localDateTime = getLocalDateTime(calendar);
+ if (localDateTime == null) {
+ return null;
+ }
+
+ return Timestamp.valueOf(localDateTime);
+ }
+
+ private LocalDateTime getLocalDateTime(Calendar calendar) {
+ getter.get(getCurrentRow(), holder);
+ this.wasNull = holder.isSet == 0;
+ this.wasNullConsumer.setWasNull(this.wasNull);
+ if (this.wasNull) {
return null;
}
- return new Timestamp(date.getTime());
+
+ final LocalDateTime localDateTime =
+
DateUtility.getLocalDateTimeFromEpochMilli(this.timeUnit.toMillis(holder.value));
+ final ZoneId defaultTimeZone =
Calendar.getInstance().getTimeZone().toZoneId();
Review Comment:
Hi,
initially, you have a timestamp at database which does not have an
associated time zone. It can be in any of them.
- when you invoke the method [getTimestamp(int
columnIndex)](https://docs.oracle.com/javase/8/docs/api/java/sql/ResultSet.html#getTimestamp-int-),
you are saying that the timestamp you are getting is at the default timezone
from the JVM.
- when you invoke the method [getTimestamp(int columnIndex, Calendar
cal)](https://docs.oracle.com/javase/8/docs/api/java/sql/ResultSet.html#getTimestamp-int-java.util.Calendar-),
you are saying that the timestamp you are getting is at the timezone specified
at input `cal` parameter.
Check the example I attached before. You have '2005-06-29 19:19:41' at
database.
- your JVM is in `America/Los_Angeles` and you invoke the [getTimestamp(int
columnIndex)](https://docs.oracle.com/javase/8/docs/api/java/sql/ResultSet.html#getTimestamp-int-).
At `ArrowFlightJdbcTimeStampVectorAccessor` you receives that exact timestamp
in UTC. But, you have to translate it to the same timestamp value but at
`America/Los_Angeles` (the default JVM timezone).
If you print the obtained timestamp, you will see the same value that was
at database.
Something like:
`2005-06-29 19:19:41.0`
- your JVM is in `America/Los_Angeles` and you invoke the [getTimestamp(int
columnIndex, Calendar
cal)](https://docs.oracle.com/javase/8/docs/api/java/sql/ResultSet.html#getTimestamp-int-java.util.Calendar-)
specifying `Asia/Tokyo`. Same as before, you receive the timestamp in UTC at
`ArrowFlightJdbcTimeStampVectorAccessor`, but now you have to put that same
timestamp in `Asia/Tokyo` time zone, because is the one specified at the
`getTimestamp` invokation.
When you print the obtained timestamp, you will see this:
`2005-06-29 03:19:41.0`
This is because the timestamp is printed following your JVM timezone
(America/Los_Angeles). But note that it is the expected value because you
retrieved the timestamp using `getTimestamp(index, Asia/Tokyo-calendar)`. So,
you specified that the timestamp '2005-06-29 19:19:41' is at the time zone
`Asia/Tokyo`.
If you check the difference, there are 16 hours less, because
`America/Los_Angeles` is at GMT-7 and `Asia/Tokyo` is at UTC+9. This is why the
timestamp is printed as `2005-06-29 03:19:41.0`, `America/Los_Angeles` value,
which is '2005-06-29 19:19:41.0' at `Asia/Tokyo`
--
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]
