scruz-denodo opened a new pull request, #43149: URL: https://github.com/apache/arrow/pull/43149
### Rationale for this change I opened this PR for continuing the work done at this one https://github.com/apache/arrow/pull/36519. I copy the description from there. When calling the getTimestamp method from the ArrowFlightJdbcTimeStampVectorAccessor class, the timezone of the Timestamp object returned is incorrect. The timestamp itself appears to be in GMT/UTC time but the timezone field of the Timestamp object is populated with the timezone of the JDBC client instead. Example timestamp on db: 2021-03-28T00:15:00.000 (UTC) timezone of JDBC client: PST/PDT (Vancouver Time) Calendar cal <- Calendar with UTC timezone calling getTimestamp(cal) on a result set will return a timestamp like this: 2021-03-28T00:15:00.000 (PST/PDT) where 2021-03-28T00:15:00.000 appears to be in UTC time but the timezone of the object itself is PST/PDT ### What changes are included in this PR? - Fixed: Correct behaviour is that the calendar object is used to extend the data into the timezone of the calendar object, essentially asserting that the data is at the timezone defined in the calendar object and returns a time-related object that has local date and time and local timezone - Fixed: for vectors that do store timezone information (ie. TimestampVector), the getter methods will use the timezone defined in vector as the timezone assertion and ignores the calendar object if one was passed in - Fixed: applyCalendarOffset now correctly creates a corresponding time-related object using the supplied calendar timezone and returns a time-related object that has local date and time and local timezone ### Are these changes tested? Many of the time related tests also face this issue and this fixes them all. Also tested the driver jar in a JDBC client and behaviour is fixed. Also tested behavior with Oracle and SQLServer. Test table ``` -- sqlserver create table ts_table ( c1 int, c2 datetime2 ); insert into ts_table (c1, c2) values (1, '2005-06-29 19:19:41'); -- oracle create table ts_table ( c1 int, c2 timestamp ); insert into ts_table (c1, c2) values (1, to_timestamp('2005-06-29 19:19:41', 'YYYY-MM-dd HH24:MI:SS')); ``` Attached `TestTs.zip` with sample class for testing the behavior. Obtained results (local time zone is `Europe/Madrid`) ``` Oracle... Timestamp at default tz (Central European Standard Time): 2005-06-29 19:19:41.0 Timestamp at America/Los_Angeles tz: 2005-06-30 04:19:41.0 SQL Server... Timestamp at default tz (Central European Standard Time): 2005-06-29 19:19:41.0 Timestamp at America/Los_Angeles tz: 2005-06-30 04:19:41.0 Flight SQL (16.1.0) Timestamp at default tz (Central European Standard Time): 2005-06-29 17:19:41.0 Timestamp at America/Los_Angeles tz: 2005-06-30 02:19:41.0 Flight SQL (fix ) Timestamp at default tz (Central European Standard Time): 2005-06-29 19:19:41.0 Timestamp at America/Los_Angeles tz: 2005-06-30 04:19:41.0 ``` Note than result with `America/Los_Angeles` prints the timestamp on my machine (which is at Europe/Madrid) with a difference of 9 hours. That is correct, `Europe/Madrid is 9 hours forward than `America/Los_Angeles`. With Flight-SQL JDBC driver **16.1.0** version results are wrong. With these changes returned timestamp is fine. ### Are there any user-facing changes? - No. Closes: https://github.com/apache/arrow/issues/36518 - Closes: https://github.com/apache/arrow/issues/36518 [TestTs.zip](https://github.com/user-attachments/files/16100625/TestTs.zip) -- 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]
