BUG: variable datetime dtype since Pandas 2.1.0

[sergiykhan]

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 pandas as pd

df = pd.DataFrame()

df['date1'] = pd.Timestamp.now()
df['date2'] = pd.Timestamp('now')
df['date3'] = pd.Timestamp('2023-11-08 11:13:14')

df.dtypes

Issue Description

Three columns above have three different types:

date1    datetime64[us]
date2    datetime64[ns]
date3     datetime64[s]

This is rather unexpected behavior. I could not find an explanation for it on https://pandas.pydata.org/docs/dev/whatsnew/v2.1.0.html#

Expected Behavior

date1    datetime64[ns]
date2    datetime64[ns]
date3    datetime64[ns]

Installed Versions

INSTALLED VERSIONS

commit : a60ad39
python : 3.11.5.final.0
python-bits : 64
OS : Linux
OS-release : 5.10.102.1-microsoft-standard-WSL2
Version : #1 SMP Wed Mar 2 00:30:59 UTC 2022
machine : x86_64
processor : x86_64
byteorder : little
LC_ALL : en_US.UTF-8
LANG : en_US.UTF-8
LOCALE : en_US.UTF-8

pandas : 2.1.2
numpy : 1.24.2
pytz : 2023.3.post1
dateutil : 2.8.2
setuptools : 65.5.0
pip : 23.3.1
Cython : None
pytest : None
hypothesis : None
sphinx : None
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : None
pymysql : None
psycopg2 : 2.9.6
jinja2 : None
IPython : 8.16.1
pandas_datareader : None
bs4 : None
bottleneck : None
dataframe-api-compat: None
fastparquet : None
fsspec : None
gcsfs : None
matplotlib : 3.8.0
numba : None
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : None
pyreadstat : None
pyxlsb : None
s3fs : None
scipy : None
sqlalchemy : 1.4.49
tables : None
tabulate : None
xarray : None
xlrd : None
zstandard : None
tzdata : 2023.3
qtpy : None
pyqt5 : None

[sergiykhan]

Ok, after more digging, found it to be a duplicate of #52653.

[sergiykhan]

Although I am still puzzled by the difference

pd.Timestamp.now().to_datetime64().dtype
dtype('<M8[us]')

pd.Timestamp('now').to_datetime64().dtype
dtype('<M8[ns]')

[lithomas1]

I think the last one is expected.

Timestamp.now() also basically does Timestamp(datetime.datetime.now()), and datetime.now gives a timestamp with resolution up to microseconds for me, so that output also seems expected.

I think the bug is probably that Timestamp('now') returns something with nanosecond resolution.

cc @jbrockmendel @MarcoGorelli

[jbrockmendel]

Agreed Timestamp("now") (also "today" should probably give "us" unit.