BUG: ensure_datetime64ns with bigendian array #30976
Conversation
| @@ -99,6 +99,11 @@ def ensure_datetime64ns(arr: ndarray, copy: bool=True): | |||
|
|
|||
| shape = (<object>arr).shape | |||
|
|
|||
| if (<object>arr).dtype.byteorder == ">": | |||
| # GH#29684 we incorrectly get OutOfBoundsDatetime if we dont swap | |||
There was a problem hiding this comment.
Do you know where this actually is causing the problem? Are we doing some low level byte swapping elsewhere in our code or just something getting thrown off in interfacing with numpy?
There was a problem hiding this comment.
When we do the arr.view(np.int64) that view is little-endian
simonjayhawkins
added
the
Regression
|
I think a test that directly hits the user-facing behavior of |
|
What do people think about backporting this? IMO it's appropriate for 1.0.1, but we don't have backports to that setup yet. So 1.0.0 is probably best. We also need a whatsnew for this, but that depends on the decision for where this should go. |
|
I guess I view 1.0.1 as reserved for regressions introduced in 1.0 which this wouldn't fall under, so very soft preference for 1.1 but not losing sleep in either case |
|
-1 on backporting this; we have very little support for big-endian at all and no testing. In fact, @jbrockmendel how do you know this actually works? |
Because you can pass a big-endian dtype even on a little-endian system. The added test does this. |
disagree; we cannot reproduce the error. It would be ok to have the OP try to repro with this patch though. Not objecting to the change, but we don't have any testing whatsoever. |
We can. Try the tests this adds on master. |
we don't have tests on a big-endian CI. |
I'm aware. I'm saying that when I run the test on my little-endian computer, it fails in master and passes after this PR. |
|
k thanks @jbrockmendel not harassing you about testing, just skeptical of big-endian testing generally |
black pandasgit diff upstream/master -u -- "*.py" | flake8 --diff