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

In [28]: import pandas as pd

In [29]: p = pd.Series([123123000123123, 1323123132, 23123123123], dtype='datetime64[ns]')

In [30]: p
Out[30]: 
0   1970-01-02 10:12:03.000123123
1   1970-01-01 00:00:01.323123132
2   1970-01-01 00:00:23.123123123
dtype: datetime64[ns]

In [31]: p.dt.second
Out[31]: 
0     3
1     1
2    23
dtype: int64

In [32]: p.dt.nanosecond
Out[32]: 
0    123
1    132
2    123
dtype: int64

In [33]: p.dt.microsecond
Out[33]: 
0       123
1    323123
2    123123
dtype: int64

Issue Description

When second & nanosecond are being accessed, the results being returned are consistent with expectations i.e., only the second & nanosecond components of the times. But when microsecond is accessed, a result of combining millisecond & microsecond are being returned. This doesn't seem to be consistent with the way other properties return their results.

This is also a Feature request to have the millisecond property added to DatetimeProperties.

Expected Behavior

In [33]: p.dt.microsecond
Out[33]: 
0    123
1    123
2    123
dtype: int64

In [37]: p.dt.millisecond
Out[37]: 
0      0
1    323
2    123
dtype: int16

Installed Versions

In [38]: pd.show_versions() /nvme/0/pgali/envs/cudfdev/lib/python3.9/site-packages/_distutils_hack/__init__.py:33: UserWarning: Setuptools is replacing distutils. warnings.warn("Setuptools is replacing distutils.") INSTALLED VERSIONS ------------------ commit : 87cfe4e38bafe7300a6003a1d18bd80f3f77c763 python : 3.9.13.final.0 python-bits : 64 OS : Linux OS-release : 4.15.0-76-generic Version : #86-Ubuntu SMP Fri Jan 17 17:24:28 UTC 2020 machine : x86_64 processor : x86_64 byteorder : little LC_ALL : None LANG : en_US.UTF-8 LOCALE : en_US.UTF-8 pandas : 1.5.0 numpy : 1.23.3 pytz : 2022.4 dateutil : 2.8.2 setuptools : 65.4.1 pip : 22.2.2 Cython : 0.29.32 pytest : 7.1.3 hypothesis : 6.56.2 sphinx : 5.2.3 blosc : None feather : None xlsxwriter : None lxml.etree : None html5lib : None pymysql : None psycopg2 : None jinja2 : 3.1.2 IPython : 8.5.0 pandas_datareader: None bs4 : 4.11.1 bottleneck : None brotli : fastparquet : None fsspec : 2022.8.2 gcsfs : None matplotlib : None numba : 0.56.2 numexpr : None odfpy : None openpyxl : None pandas_gbq : None pyarrow : 9.0.0 pyreadstat : None pyxlsb : None s3fs : 2022.8.2 scipy : 1.9.1 snappy : sqlalchemy : 1.4.41 tables : None tabulate : 0.9.0 xarray : None xlrd : None xlwt : None zstandard : None tzdata : None

Comment From: mroeschke

Going to restructure this issue as an enhancement request since this stems from millisecond not being supported and the return of microsecond is consistent with datetime.datetime that also doesn't support millisecond.

Also if pandas supports millisecond, I think .microsecond should still match the datetime.datetime behavior since the "base" Timestamp tries to be fully compatible with it.

Comment From: PedroPUCRIO

take

Comment From: MarcoGorelli

If I've understood correctly, I think I'd be -1 on adding milliseconds

Suppose one had

In [30]: ts
Out[30]: Timestamp('2000-01-01 01:01:01.123456789')

In [31]: ts.millisecond
Out[31]: 123

Then one might well expect to get 123456789 from the following, instead of 246456789

In [32]: ts.millisecond * 1_000_000 + ts.microsecond * 1_000 + ts.nanosecond
Out[32]: 246456789

This could be resolved by making ts.microsecond return 456 instead, but that'd be a breaking change from the Python standard library.

To minimise surprises to users, I'd advocate for staying consistent with the Python standard library: - no millisecond - microsecond stays as-is

Comment From: MarcoGorelli

closing for now then, but thanks for the suggestion!