Pandas version checks
-
[x] I have checked that this issue has not already been reported.
-
[x] 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
(Pdb) pd.DataFrame({"0": [datetime.fromtimestamp(1568888888, tz=pytz.utc)]}).dtypes
0 datetime64[ns, UTC]
dtype: object
(Pdb) pd.DataFrame({"0": datetime.fromtimestamp(1568888888, tz=pytz.utc)}, index=[0]).dtypes
0 datetime64[us, UTC]
dtype: object
(Pdb)
Issue Description
When creating a Pandas DataFrame with a timezone-aware datetime object (e.g., datetime.datetime with tzinfo=pytz.UTC), the inferred datetime64 precision differs depending on whether the datetime is passed as a scalar or inside a list. This leads to inconsistent and potentially unexpected behavior
Expected Behavior
Both DataFrame initializations should infer the same datetime dtype (datetime64[ns, UTC]), ideally following Pandas’ default precision of nanoseconds.
Installed Versions
>>> pd.show_versions()
INSTALLED VERSIONS
------------------
commit : c888af6d0bb674932007623c0867e1fbd4bdc2c6
python : 3.13.5
python-bits : 64
OS : Linux
OS-release : 6.8.0-47-generic
Version : #47-Ubuntu SMP PREEMPT_DYNAMIC Fri Sep 27 22:03:50 UTC 2024
machine : aarch64
processor :
byteorder : little
LC_ALL : None
LANG : en_US.UTF-8
LOCALE : C.UTF-8
pandas : 2.3.1
numpy : 2.3.2
pytz : 2025.2
dateutil : 2.9.0.post0
pip : None
Cython : None
sphinx : 8.2.3
IPython : 9.4.0
adbc-driver-postgresql: None
adbc-driver-sqlite : None
bs4 : None
blosc : None
bottleneck : None
dataframe-api-compat : None
fastparquet : None
fsspec : None
html5lib : None
hypothesis : None
gcsfs : None
jinja2 : 3.1.6
lxml.etree : None
matplotlib : None
numba : None
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
psycopg2 : 2.9.10
pymysql : None
pyarrow : 21.0.0
pyreadstat : None
pytest : 8.4.1
python-calamine : None
pyxlsb : None
s3fs : None
scipy : 1.16.0
sqlalchemy : None
tables : None
tabulate : None
xarray : None
xlrd : None
xlsxwriter : None
zstandard : None
tzdata : 2025.2
qtpy : None
pyqt5 : None
>>>
Comment From: jbrockmendel
These both correctly give microsecond dtype on main. Can you confirm