-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
BUG: DatetimeArray.unit when constructed from a non-nano ndarray #52555
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
Conversation
doc/source/whatsnew/v2.1.0.rst
Outdated
@@ -219,6 +219,7 @@ Datetimelike | |||
- Bug in :meth:`Timestamp.round` with values close to the implementation bounds returning incorrect results instead of raising ``OutOfBoundsDatetime`` (:issue:`51494`) | |||
- :meth:`DatetimeIndex.map` with ``na_action="ignore"`` now works as expected. (:issue:`51644`) | |||
- Bug in :meth:`arrays.DatetimeArray.map` and :meth:`DatetimeIndex.map`, where the supplied callable operated array-wise instead of element-wise (:issue:`51977`) | |||
- Bug in :class:`arrays.DatetimeArray` constructor returning an incorrect unit when passed a non-nanosecond numpy datetime array (:issue:`52555`) |
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 it would be okay to backport this to 2.0.1
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.
moved to 2.0.1 - thanks
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.
Merge conflict otherwise LGTM
Thanks @lukemanley |
…d from a non-nano ndarray
…tructed from a non-nano ndarray) (#52608) Backport PR #52555: BUG: DatetimeArray.unit when constructed from a non-nano ndarray Co-authored-by: Luke Manley <[email protected]>
doc/source/whatsnew/v2.1.0.rst
file if fixing a bug or adding a new feature.fixes the following inconsistency: