issue_comments: 1250058482

This data as json

html_url issue_url id node_id user created_at updated_at author_association body reactions performed_via_github_app issue
https://github.com/pydata/xarray/issues/6906#issuecomment-1250058482 https://api.github.com/repos/pydata/xarray/issues/6906 1250058482 IC_kwDOAMm_X85KgmDy 6628425 2022-09-17T12:00:26Z 2022-09-17T12:20:41Z MEMBER

I was able to reproduce this issue in a Docker container using the s390x Debian image. After a little experimentation I narrowed it down to the following minimal example: ```

import numpy as np; import pandas as pd np.version '1.23.3' pd.version '1.4.4' pd.Series(np.array([1]).astype("<M8[h]")) Traceback (most recent call last): File "\<stdin>", line 1, in \<module> File "/usr/local/lib/python3.9/dist-packages/pandas/core/series.py", line 451, in __init__ data = sanitize_array(data, index, dtype, copy) File "/usr/local/lib/python3.9/dist-packages/pandas/core/construction.py", line 570, in sanitize_array subarr = _try_cast(data, dtype, copy, raise_cast_failure) File "/usr/local/lib/python3.9/dist-packages/pandas/core/construction.py", line 729, in _try_cast return sanitize_to_nanoseconds(arr, copy=copy) File "/usr/local/lib/python3.9/dist-packages/pandas/core/dtypes/cast.py", line 1717, in sanitize_to_nanoseconds values = conversion.ensure_datetime64ns(values) File "pandas/_libs/tslibs/conversion.pyx", line 257, in pandas._libs.tslibs.conversion.ensure_datetime64ns File "pandas/_libs/tslibs/np_datetime.pyx", line 120, in pandas._libs.tslibs.np_datetime.check_dts_bounds pandas._libs.tslibs.np_datetime.OutOfBoundsDatetime: Out of bounds nanosecond timestamp: 8220291319602-05-05 16:00:00 This confirms it is an upstream issue. Interestingly if we use the native byte order (big-endian on this architecture) for the dtype, this example works: pd.Series(np.array([1]).astype("M8[h]")) 0 1970-01-01 01:00:00 dtype: datetime64[ns] or more explicitly pd.Series(np.array([1]).astype(">M8[h]")) 0 1970-01-01 01:00:00 dtype: datetime64[ns] ``` It appears the inverse of this issue (big-endian dtype leading to a failure on a little-endian system) came up once in pandas: https://github.com/pandas-dev/pandas/issues/29684. @amckinstry I'm not sure what it will take to fix this issue in pandas, but you are welcome to open an issue there. They may also have a difficult time reproducing and testing this, however (https://github.com/pandas-dev/pandas/pull/30976#issuecomment-573989082).

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   1334835539