hsdfat opened a new pull request, #12007:
URL: https://github.com/apache/arrow-rs/pull/12007
# Which issue does this PR close?
- None; small bug fix.
# Rationale for this change
When a JSON number for a `Timestamp` column doesn't parse as `i64`, the
reader falls back to `f64` and casts with `as i64`, which saturates. `{"time":
1e30}` read as `Timestamp(Second)` silently becomes `i64::MAX`, and displaying
the batch then fails with `Cast error: Failed to convert 9223372036854775807 to
timestamp`.
The primitive decoder (Int64, Date32, Time, Duration) uses `NumCast::from`
for the same fallback. So an out-of-range float is a "failed to parse" error
there, or null with `with_ignore_type_conflicts(true)`. Timestamps did neither.
# What changes are included in this PR?
The timestamp decoder uses the same `NumCast::from` fallback as
`primitive_array.rs`. In-range values, including fractional ones that truncate,
are unchanged.
# Are these changes tested?
Yes. `test_timestamp_float_out_of_range` covers ±1e30, 2^63, 1e999 (error,
or null when ignoring type conflicts) and -2^63 (still `i64::MIN`).
# Are there any significant user-facing changes?
Out-of-range float timestamps now produce an error (or null with
`with_ignore_type_conflicts`) instead of a saturated `i64::MAX` / `i64::MIN`,
matching the other numeric types.
---
AI disclosure: the bug was found and the patch and test drafted with AI
assistance (Claude); I reviewed every line, verified the failing test
before/after the fix, and ran fmt/clippy/tests for the crate.
--
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]
