Shahzeb-DataEngineer opened a new issue, #11853: URL: https://github.com/apache/arrow-rs/issues/11853
## Describe the bug Casting a `Date64` array to `Date32` returns the wrong calendar date for negative (pre-1970) values that are not an exact midnight. The `(Date64, Date32)` arm in `arrow-cast/src/cast/mod.rs` computes the day as `x / MILLISECONDS_IN_DAY`, and Rust integer division truncates toward zero, so a pre-epoch instant is rounded *up* to the next day instead of down to the day that contains the instant. Every sibling conversion in the crate floors instead: `cast_timestamp_to_date` in `arrow-cast/src/cast/temporal.rs` uses `div_euclid`, which is also the semantics adopted for Timestamp -> Date64 in #11632. ## Reproduction Date64 inputs (milliseconds since epoch) cast to Date32: | Input (ms) | Instant (UTC) | Expected Date32 | Actual Date32 | | --- | --- | --- | --- | | -1 | 1969-12-31 23:59:59.999 | -1 | 0 | | -86399999 | 1969-12-31 00:00:00.001 | -1 | 0 | | -86400001 | 1969-12-30 23:59:59.999 | -2 | -1 | | 86399999 | 1970-01-01 23:59:59.999 | 0 | 0 | The wrong result is produced in both safe and unsafe cast modes. The existing tests for this cast (`test_cast_date64_to_date32`, `test_cast_date64_to_date32_overflow`) only use positive values, where truncation and flooring agree, so the gap is not covered. ## Expected behavior Date64 -> Date32 should use floor semantics (`div_euclid`), consistent with the Timestamp -> Date32 and Timestamp -> Date64 conversions in the same crate. I have a fix ready and will open a PR shortly. -- 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]
