parser: round microsecond half-up when truncated value has trailing non-zero digits#1323
Open
HrachShah wants to merge 1 commit into
Open
parser: round microsecond half-up when truncated value has trailing non-zero digits#1323HrachShah wants to merge 1 commit into
HrachShah wants to merge 1 commit into
Conversation
…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.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1323 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 10 10
Lines 2315 2317 +2
Branches 358 359 +1
=========================================
+ Hits 2315 2317 +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
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.
Bug
arrow.parser.DateTimeParserrounds the 'S' sub-second token to 6 digits using only the 7th digit. When the 7th digit is 5, it applies round-half-to-even (banker's rounding) based purely on the parity of the 6th digit, ignoring everything that follows.A value like
.789124501therefore rounds to789124(banker's: 4 is even), but the true value is strictly above the half-way point between789124and789125and should round to789125. The same is true for.789124511,.789123550001, and any other input where the 7th digit is 5 and a non-zero digit trails it.Repro
Fix
Restrict the banker's-rounding branch to the case where the 7th digit is 5 and every following digit is zero. If any non-zero digit trails the 5, the truncated 6-digit value sits strictly above the midpoint, so round up regardless of parity:
Tests
test_parse_subsecond_rounding(the "round half-down" / "round half-up" cases were pinning the bug).test_gnu_date(date -Insoutput that has 9 sub-second digits is now rounded correctly).test_YYYY_MM_DDTHH_mm_ss_S_round_half_upcovering all four corners: banker's with even 6th / trailing zeros, banker's with odd 6th / trailing zeros, strict half-up with non-zero trailing, and strict above/below the half-way point.Full test suite: 1905 passed, 1 skipped (up from 1904 — the new test). The 2 pre-existing errors in
tests/utils.py(assertion helpers being collected as test items) are unrelated.