AbhishekPathania opened a new pull request, #1294: URL: https://github.com/apache/arrow-java/pull/1294
## What's Changed `DateTimeUtils.getTimestampValue` split epoch millis into an epoch day and a time-of-day remainder using `/` and `%`, which truncate toward zero. Only the remainder half compensated for negative input (`LocalTime.ofNanoOfDay` rejects negatives), while the epoch-day half did not. For any negative value that is not an exact multiple of a day the two halves therefore described different days, and the returned timestamp was one day later than the instant it was given. Worked example: `-618102000000` is 1950-06-01 01:00:00 UTC. `-618102000000 / 86400000` truncates to `-7153`, i.e. 1950-06-02, while the remainder is the 01:00:00 of 1950-06-01, so the method returned `1950-06-02 01:00:00`. This is reachable through `ArrowFlightJdbcDateVectorAccessor.getDate(Calendar)`: a date vector value is day-aligned on its own, but `DateTimeUtils.applyCalendarOffset` shifts it off that alignment whenever the supplied `Calendar` uses a zone other than the JVM default, so every pre-1970 date came back a day late. The fix uses `Math.floorDiv` and `Math.floorMod` for both halves, which keeps the day and the remainder on the same day and makes the manual negative adjustment redundant. Positive input is unaffected, since both functions agree with `/` and `%` there. The existing negative-input test used an exact midnight value, where truncating and flooring division agree, so it could not catch this. `DateTimeUtilsTest` gains a case one hour past midnight on the same pre-epoch day, which fails before this change and passes after it. Closes #1293. -- 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]
