BUG: to_datetime wraps datetime64[ps] as if it were datetime64[ns]

[kmuehlbauer]

Pandas version checks

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pandas.

• I have confirmed this bug exists on the main branch of pandas.

Reproducible Example

import numpy as np
import pandas as pd

print("Good:", pd.to_datetime([np.datetime64(1901901901901, "as")]))
print("Good:", pd.to_datetime([np.datetime64(1901901901901, "fs")]))
print(" Bad:", pd.to_datetime([np.datetime64(1901901901901, "ps")]))
print("Good:", pd.to_datetime([np.datetime64(1901901901901, "ns")]))
print("Good:", pd.to_datetime([np.datetime64(1901901901901, "us")]))
print("Good:", pd.to_datetime([np.datetime64(1901901901901, "ms")]))


# Good: DatetimeIndex(['1970-01-01 00:00:00.000001901'], dtype='datetime64[ns]', freq=None)
# Good: DatetimeIndex(['1970-01-01 00:00:00.001901901'], dtype='datetime64[ns]', freq=None)
#  Bad: DatetimeIndex(['1970-01-01 00:31:41.901901901'], dtype='datetime64[ns]', freq=None)
# Good: DatetimeIndex(['1970-01-01 00:31:41.901901901'], dtype='datetime64[ns]', freq=None)
# Good: DatetimeIndex(['1970-01-23 00:18:21.901901'], dtype='datetime64[ns]', freq=None)
# Good: DatetimeIndex(['2030-04-08 18:05:01.901000'], dtype='datetime64[ns]', freq=None)

Issue Description

Wrapping np.datetime64[ps] data with pd.to_datetime is wrongly converted as if it were np.datetime64[ns].

Expected Behavior

DatetimeIndex(['1970-01-01 00:00:01.901901901'], dtype='datetime64[ns]', freq=None)

Installed Versions

INSTALLED VERSIONS

commit : d9cdd2e
python : 3.12.5.final.0
python-bits : 64
OS : Linux
OS-release : 5.15.0-122-generic
Version : #132-Ubuntu SMP Thu Aug 29 13:45:52 UTC 2024
machine : x86_64
processor : x86_64
byteorder : little
LC_ALL : None
LANG : de_DE.UTF-8
LOCALE : de_DE.UTF-8
pandas : 2.2.2
numpy : 2.1.1
pytz : 2024.2
dateutil : 2.9.0
setuptools : 73.0.1
pip : 24.2
Cython : None
pytest : 8.3.3
hypothesis : None
sphinx : None
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : None
pymysql : None
psycopg2 : None
jinja2 : 3.1.4
IPython : 8.28.0
pandas_datareader : None
adbc-driver-postgresql: None
adbc-driver-sqlite : None
bs4 : 4.12.3
bottleneck : None
dataframe-api-compat : None
fastparquet : None
fsspec : 2024.9.0
gcsfs : None
matplotlib : 3.9.2
numba : None
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : 17.0.0
pyreadstat : None
python-calamine : None
pyxlsb : None
s3fs : 2024.9.0
scipy : 1.14.1
sqlalchemy : None
tables : None
tabulate : None
xarray : 2024.10.0
xlrd : None
zstandard : 0.23.0
tzdata : 2024.1
qtpy : None
pyqt5 : None

[kmuehlbauer]

This was encountered while in an attempt to relax nanosecond resolution over at xarray (pydata/xarray#9618).

[yuanx749]

take

[yuanx749]

Can confirm on main. The bug is from wrong conversion for "ps" case in the C code.

[jorisvandenbossche]

@kmuehlbauer thanks for the report, and @yuanx749 thanks for looking into it!

[yuanx749]

I've submitted a PR (with a simple test).

[kmuehlbauer]

Thanks all!