BUG: to_datetime with out-of-bounds np.datetime64 and errors='ignore' doesn't return input #50992
Conversation
doc/source/whatsnew/v2.0.0.rst Outdated
| - Bug in :func:`to_datetime` was raising ``ValueError`` when parsing mixed-offset :class:`Timestamp` with ``errors='ignore'`` (:issue:`50585`) | ||
| - Bug in :func:`to_datetime` was incorrectly handling floating-point inputs within 1 ``unit`` of the overflow boundaries (:issue:`50183`) | ||
| - Bug in :func:`to_datetime` with unit of "Y" or "M" giving incorrect results, not matching pointwise :class:`Timestamp` results (:issue:`50870`) | ||
| - Bug in :func:`to_datetime` was not returning input with ``errors='ignore'`` when passed out-of-bounds np.datetime64 (:issue:`50587`) |
There was a problem hiding this comment.
this sounds like it is just np.datetime64 objects, but i think it can also be strings or ints/floats
| tm.assert_index_equal( | ||
| to_datetime(dts_with_oob, errors="ignore", cache=cache), | ||
| Index([dt.item() for dt in dts_with_oob]), | ||
| Index(dts_with_oob), |
There was a problem hiding this comment.
can you write a small dedicated test for this. iirc some of the non-nano stuff is liable to change this test and i dont want to accidentally get rid of coverage for this behavior
| I'm on board with this change, should probably make sure others agree |
sure - @mroeschke any objections? Anyone I should ping who might be opinionated on this? |
mroeschke left a comment
mroeschke left a comment There was a problem hiding this comment.
Sounds good. Guessing we have tests for the errors='coerce' behavior?
| thanks! and yes, errors='coerce' with oob is covered, e.g. pandas/pandas/tests/tools/test_to_datetime.py Lines 1089 to 1095 in 4a61e6a |
| Thanks @MarcoGorelli (failure unrelated) |
| nice! |
3 participants
doc/source/whatsnew/vX.X.X.rstfile if fixing a bug or adding a new feature.