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

Comment From: cosmic-heart

These both correctly give microsecond dtype on main. Can you confirm

Yes, I’m getting microseconds for both initializations from the main branch. However, I noticed that the main branch has been tagged as 3.0.0-dev branch. Will this fix also be backported to any upcoming 2.x releases?

Additionally, shouldn’t the default datetime object be in nanoseconds, as it was in pandas 1.x?

Comment From: jbrockmendel

Will this fix also be backported to any upcoming 2.x releases?

No, this is not a "fix" but an API change in 3.0 to do resolution inference in the non-scalar case.

Additionally, shouldn’t the default datetime object be in nanoseconds, as it was in pandas 1.x?

No, we do resolution inference based on the input. In this case the input is a python datetime object which has microsecond resolution.

Comment From: cosmic-heart

But in version 2.3.1, the same datetime object behaves differently depending on how it’s initialized, when created as an array, it retains nanosecond precision, whereas initializing it with index=[0] results in microsecond precision. Doesn’t that seem like a bug?

Comment From: jbrockmendel

We definitely want it to behave the same, which is why we implemented resolution inference for sequences for 3.0. But backporting that is not viable, and everything is behaving as expected/documented in 2.3.1.