-
-
Notifications
You must be signed in to change notification settings - Fork 18.6k
BUG: Raise OutOfBoundsDatetime in DataFrame.replace when value exceeds datetime64[ns] bounds (GH#61671) #61717
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
…time64[ns] (GH#61671)
looking into the CI failures |
Regarding CI failures — So after the changes in Because of that, Happy to revert or gate the check if needed. |
if ( | ||
is_datetime64_dtype(new_dtype) | ||
and lib.is_scalar(right) | ||
and isinstance(right, (np.datetime64, dt.datetime, Timestamp)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the Timestamp check is redundant bc it is a subclass of datetime
raise OutOfBoundsDatetime( | ||
f"{right!r} overflows datetime64[ns] during dtype inference" | ||
) | ||
except (OverflowError, ValueError) as e: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nitpick can you call this err
instead of e
. try to avoid 1-letter variable names
and isinstance(right, (np.datetime64, dt.datetime, Timestamp)) | ||
): | ||
try: | ||
ts = Timestamp(right) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think ts.as_unit("ns")
will be more robust to if there is a timezone
@@ -1358,6 +1359,24 @@ def find_result_type(left_dtype: DtypeObj, right: Any) -> DtypeObj: | |||
dtype, _ = infer_dtype_from(right) | |||
new_dtype = find_common_type([left_dtype, dtype]) | |||
|
|||
# special case: datetime64[ns] inferred but the value may be out of bounds |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you add something like "# GH#61671" here
# GH 61671 | ||
df = DataFrame([np.nan], dtype="datetime64[ns]") | ||
too_big = datetime(3000, 1, 1) | ||
from pandas.errors import OutOfBoundsDatetime |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can this import go at the top of the file
@@ -1430,6 +1430,18 @@ def test_replace_with_nil_na(self): | |||
result = ser.replace("nil", "anything else") | |||
tm.assert_frame_equal(expected, result) | |||
|
|||
def test_replace_outofbounds_datetime_raises(self): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you parametrize this over tz=[None, "US/Eastern"]?
Fixes a bug where
DataFrame.replace
would raise a genericAssertionError
when trying to replacenp.nan
in adatetime64[ns]
column with an out-of-boundsdatetime.datetime
object (e.g.,datetime(3000, 1, 1)
).This PR fixes that by explicitly raising
OutOfBoundsDatetime
when the replacement datetime can't safely fit into thedatetime64[ns]
dtype.Datetimelike
for 3.0.0Let me know if you'd like to test other edge cases or if there's a more idiomatic way to handle this!