is_timestamp: reject NaN and ±inf so callers fail with a clear ValueError - #1324
Open
HrachShah wants to merge 3 commits into
Open
is_timestamp: reject NaN and ±inf so callers fail with a clear ValueError#1324HrachShah wants to merge 3 commits into
HrachShah wants to merge 3 commits into
Conversation
added 3 commits
July 11, 2026 17:32
…on-zero digits The 'S' token rounds a sub-second value to the nearest 6-digit microsecond, but the half-way case was unconditionally applying round-half-to-even (banker's rounding) based purely on the 6th digit. That ignored anything after the 7th digit, so a value like .7891235001 lost the trailing '001' and was rounded down to .789123 even though the true value sits above the half-way point and should round up to .789124. Restrict the banker's-rounding branch to the case where the 7th digit is exactly 5 and all following digits are zero. When non-zero digits follow, the truncated 6-digit value is strictly greater than the midpoint between two adjacent microseconds, so round up regardless of the parity of the 6th digit. Updated test_parse_subsecond_rounding and test_gnu_date which had pinned the old behaviour, and added test_YYYY_MM_DDTHH_mm_ss_S_round_half_up covering the banker's / strict half-up / strictly-above / strictly-below corners.
_Build_datetime called datetime.strptime with the G/V/u format string for
ISO 8601 weekdates, but a year like 2024 has no week 53 (only 2020, 2026,
and a handful of long-ISO years do). The bare strptime raised a ValueError
that escaped through DateTimeParser.parse and parse_iso, so a user passing
'2024-W53-1' saw a bare ValueError('Invalid week: 53') with no context
about which year/week string they had typed, instead of a ParserError
naming the offending input.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1324 +/- ##
===========================================
- Coverage 100.00% 99.91% -0.09%
===========================================
Files 10 10
Lines 2315 2321 +6
Branches 358 347 -11
===========================================
+ Hits 2315 2319 +4
- Misses 0 2 +2 ☔ View full report in Codecov by Harness. |
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
1 participant
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.
Replaces the 'parse as float and accept' check in
is_timestampwith one that also requires the parsed value to be finite.float('nan'),float('inf'), andfloat('-inf')all parse cleanly today and passis_timestamp, soArrow.fromtimestampthen raises a genericValueErrorfor NaN/inf or anOverflowErrorfor -inf — neither names the actual problem ("this is not a timestamp").Arrow.fromtimestamp(0.0 / 0.0)etc. should surface asValueError("The provided timestamp NaN is invalid.")at the call site, not as a confusing overflow error from inside the stdlib.