Repository navigation
Conversation
`ScalarValue::Date64` formatting unwrapped `chrono::Duration::try_milliseconds`, which returns `None` for `i64::MIN` because that value is below the range `chrono::Duration` can represent. Any plan that prints such a literal, for example `EXPLAIN SELECT arrow_cast(-9223372036854775808, 'Date64')`, panicked with "called `Option::unwrap()` on a `None` value". Chain the two fallible steps instead so an unrepresentable date formats as an empty string, the same way an out-of-range epoch offset already does. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
edubraqd
marked this pull request as draft
September 4, 2026 13:18
Contributor
Contributor
|
Closing per #24893 (comment) |
This was referenced Sep 11, 2026
tjnangosha
pushed a commit
to tjnangosha/datafusion
that referenced
this pull request
Oct 8, 2026
…#26139) ## Which issue does this PR close? - Closes apache#24892. ## Rationale for this change `impl fmt::Display for ScalarValue` unwraps `chrono::Duration::try_milliseconds(v)` in the `Date64` arm. That returns `None` for `i64::MIN`, which `Duration` cannot represent, so printing such a literal panics, for example `EXPLAIN SELECT arrow_cast(-9223372036854775808, 'Date64')`. apache#24893 proposed the same change and was closed as part of a batch of PRs, not on its merits. This PR redoes it on current `main`. ## What changes are included in this PR? `try_milliseconds` and `checked_add_signed` are chained with `and_then`, so a value `Duration` cannot hold falls into the existing `None => ""` branch. That's how the neighbouring out-of-range case already formats (added for apache/arrow-rs#7728). One file, +7/-1. ## What is the testing strategy for this PR? `test_display_date64_large_values` now also checks `i64::MIN` and `i64::MAX`: - Without the fix it panics at the same `unwrap` (`scalar/mod.rs:5651`). - With the fix, `cargo test -p datafusion-common --lib` passes 623 tests, and `rustfmt --check` is clean. `cargo clippy -p datafusion-common --all-targets -- -D warnings` fails locally on an unused import in `config.rs:4157`. That happens on unmodified `main` too, probably because I ran without the `parquet` feature, so it's unrelated. **Not verified:** the issue's second reproduction, a `RANGE` window frame over a `Date64` column containing `i64::MIN`. I only ran the unit test. If that path panics somewhere other than this `Display` impl, this PR doesn't fix it. ## Are there any user-facing changes? No panic: a `Date64` of `i64::MIN` displays as an empty string, like other out-of-range dates. **AI disclosure:** prepared with Claude Code (Claude Opus 5.5), which wrote the change and the test and ran the commands above. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Omega359
pushed a commit
to Omega359/arrow-datafusion
that referenced
this pull request
Oct 11, 2026
…#26139) ## Which issue does this PR close? - Closes apache#24892. ## Rationale for this change `impl fmt::Display for ScalarValue` unwraps `chrono::Duration::try_milliseconds(v)` in the `Date64` arm. That returns `None` for `i64::MIN`, which `Duration` cannot represent, so printing such a literal panics, for example `EXPLAIN SELECT arrow_cast(-9223372036854775808, 'Date64')`. apache#24893 proposed the same change and was closed as part of a batch of PRs, not on its merits. This PR redoes it on current `main`. ## What changes are included in this PR? `try_milliseconds` and `checked_add_signed` are chained with `and_then`, so a value `Duration` cannot hold falls into the existing `None => ""` branch. That's how the neighbouring out-of-range case already formats (added for apache/arrow-rs#7728). One file, +7/-1. ## What is the testing strategy for this PR? `test_display_date64_large_values` now also checks `i64::MIN` and `i64::MAX`: - Without the fix it panics at the same `unwrap` (`scalar/mod.rs:5651`). - With the fix, `cargo test -p datafusion-common --lib` passes 623 tests, and `rustfmt --check` is clean. `cargo clippy -p datafusion-common --all-targets -- -D warnings` fails locally on an unused import in `config.rs:4157`. That happens on unmodified `main` too, probably because I ran without the `parquet` feature, so it's unrelated. **Not verified:** the issue's second reproduction, a `RANGE` window frame over a `Date64` column containing `i64::MIN`. I only ran the unit test. If that path panics somewhere other than this `Display` impl, this PR doesn't fix it. ## Are there any user-facing changes? No panic: a `Date64` of `i64::MIN` displays as an empty string, like other out-of-range dates. **AI disclosure:** prepared with Claude Code (Claude Opus 5.5), which wrote the change and the test and ran the commands above. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Which issue does this PR close?
Date64scalar ofi64::MINpanics #24892.Rationale for this change
ScalarValue::Date64formatting unwrapschrono::Duration::try_milliseconds, which isNonefori64::MIN. Printing such a literal, for exampleEXPLAIN SELECT arrow_cast(-9223372036854775808, 'Date64'), panics instead of producing a plan.What changes are included in this PR?
Chain
try_millisecondsandchecked_add_signedwithand_then, so a value thatchrono::Durationcannot hold is treated the same as a date that is out of range: it formats as an empty string, which is what the existing out-of-range handling (added for apache/arrow-rs#7728) already does.Are these changes tested?
Yes.
test_display_date64_large_valuesnow also coversi64::MIN(which used to panic) andi64::MAX.Are there any user-facing changes?
No panic when a
Date64literal ofi64::MINis displayed.