fix approx rel for timedelta: accept float, compute rel * expected#14466
Merged
Pierre-Sassoulas merged 7 commits intoMay 12, 2026
Merged
Conversation
RonnyPfannschmidt
approved these changes
May 12, 2026
The PR forgot to validate rel and abs for timedelta the same way ApproxScalar does. Without these checks, a negative rel produces a negative timedelta tolerance that makes every comparison silently return False, and NaN rel throws a confusing error message. - Raise ValueError for negative rel - Raise ValueError for NaN rel - Raise ValueError for negative abs (timedelta) - Add corresponding tests
for more information, see https://pre-commit.ci
…comparisons _approx_scalar only knew about Decimal vs scalar, so approx([timedelta(...)], rel=0.05) silently fell back to strict equality. Route datetime/timedelta elements through ApproxTimedelta instead. Also mention rel in the "requires tolerance" error message and fix the return type annotation.
for more information, see https://pre-commit.ci
…atetime The isinstance(expected, datetime) check inside the rel block was unreachable because the same condition is already caught earlier at the top of __init__. Removing it fixes the codecov/patch failure. Also add tests for two uncovered branches in _approx_scalar: - timedelta in mapping with abs tolerance (only rel was tested) - datetime in sequence and mapping (not tested at all)
Pierre-Sassoulas
requested changes
May 12, 2026
| @@ -0,0 +1 @@ | |||
| Fixed ``rel`` parameter in :func:`pytest.approx` for :class:`~datetime.timedelta` comparisons -- it was being treated as an absolute tolerance instead of a relative one. | |||
Member
There was a problem hiding this comment.
I don't think it was released, so no need for a changelog.
Contributor
Author
There was a problem hiding this comment.
Good point, removed the changelog entry. Thanks!
The rel parameter for timedelta never worked correctly in a released version, so there is no bug to document.
Pierre-Sassoulas
approved these changes
May 12, 2026
Member
Pierre-Sassoulas
left a comment
There was a problem hiding this comment.
Thank you for catching that !
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
3 participants
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.
Was looking into #14462 and noticed that the
relparam for timedelta inapproxwas being treated as an absolute tolerance -- merged withabsviamax()instead of being scaled by the expected value. Soapprox(timedelta(seconds=100), rel=timedelta(seconds=5))gave you a flat 5-second tolerance, not 5% of 100 seconds.The fix makes
relaccept a float for timedelta comparisons, same as it works for numbers. Nowapprox(td, rel=0.05)means "within 5% of the expected timedelta", which is what you'd naturally expect from a parameter calledrel. The tolerance is computed asrel * abs(expected), which works becausetimedelta * floatreturns a timedelta in Python.When both
relandabsare provided, the larger tolerance wins (same asApproxScalar).relfor datetime is still rejected with the same TypeError as before.Closes #14462