ENH: _testing.assert_almost_equal on datetimes actually checks exact equality #50191
Comments
rebecca-palmer
added
Bug
Needs Triage
|
Can we add this easily? |
|
My understanding of atol/rtol is that they are really only intended for float data. i am skeptical of extending that to datetime scalars |
|
rtol possibly doesn't make sense on datetimes because of the arbitrary zero point. atol on datetimes, and both of them on timedeltas, do make sense but may or may not be worth the effort. I'm not sure if having them explicitly raise NotImplementedError would be helpful, or if that would mostly just break use of assert_almost_equal on mixed-dtype DataFrames containing datetimes that match exactly and numbers that match only approximately. Maybe just add something along the lines of "atol/rtol ignored - only exact matching implemented for this dtype" (could probably use better wording) to the failure message? |
|
Agree on raising here, or documenting that non-exact equality is only applicable to floats (relevant issue: #55882) |
mroeschke
added
Error Reporting
mroeschke
changed the title
Pandas version checks
I have checked that this issue has not already been reported.
I have confirmed this bug exists on the latest version of pandas.
I have confirmed this bug exists on the main branch of pandas.
Reproducible Example
Issue Description
_testing.assert_almost_equal on datetimes (and probably other extension types) actually checks exact equality, because pandas/_testing/asserters.py:731 calls assert_numpy_array_equal, which doesn't have atol/rtol.
I'm not sure what should be done about this: it looks like removing that call or restricting it to check_exact=True would instead create an infinite loop, though I haven't actually tested that.
Failure log:
Expected Behavior
As the values are within the specified tolerance of each other, assert_almost_equal should pass.
(It's possibly also a bug that to_datetime(errors='raise') and to_datetime(errors='coerce') are rounded differently, but a separate one.)
Installed Versions
Probably not critical since all the CI runs failed.
(It looks like the bug also exists in stable, but I haven't actually tested that - I assume your bug reporting form's "version checks" aren't actually intended to ban reporting bugs that exist in main but not in a release.)
The text was updated successfully, but these errors were encountered: