BUG: Accessing year 2263 datetime in a dataframe using iloc raises OutOfBoundsDatetime

[RauliRuohonen]

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

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

• (optional) I have confirmed this bug exists on the master branch of pandas.

---

Code Sample, a copy-pastable example

import datetime
import pandas as pd

df = pd.DataFrame({'x': [datetime.datetime(2_263, 1, 1)]})
print(df)
print('loc:', repr(df.loc[0, 'x']))
print('iloc:', end=' ')
try:
    print(repr(df.iloc[0, 0]))
except Exception as exc:
    print(repr(exc))
print('iloc after extracting column:', repr(df['x'].iloc[0]))

Problem description

Output:

                     x
0  2263-01-01 00:00:00
loc: datetime.datetime(2263, 1, 1, 0, 0)
iloc: OutOfBoundsDatetime('Out of bounds nanosecond timestamp: 2263-01-01 00:00:00')
iloc after extracting column: datetime.datetime(2263, 1, 1, 0, 0)

When a timestamp that fits into a datetime.datetime but does not fit into a pd.Timestamp is accessed through df.iloc[0, 0], it results in OutOfBoundsDatetime being raised. In contrast, accesses through df.loc[0, 'x'] or df['x'].iloc[0] successfully return the datetime.

It'd be more predictable and consistent to have the same behavior for all three access methods. As it is, unless you've tried all these access methods with suitable datetimes, you'll never guess which of them will work and which won't.

Expected Output

                     x
0  2263-01-01 00:00:00
loc: datetime.datetime(2263, 1, 1, 0, 0)
iloc: datetime.datetime(2263, 1, 1, 0, 0)
iloc after extracting column: datetime.datetime(2263, 1, 1, 0, 0)

Output of pd.show_versions()

INSTALLED VERSIONS

commit : None
python : 3.7.5.final.0
python-bits : 64
OS : Darwin
OS-release : 18.7.0
machine : x86_64
processor : i386
byteorder : little
LC_ALL : None
LANG : en_US.UTF-8
LOCALE : en_US.UTF-8

pandas : 1.0.3
numpy : 1.18.4
pytz : 2019.3
dateutil : 2.8.1
pip : 19.2.3
setuptools : 41.2.0
Cython : 0.29.14
pytest : None
hypothesis : None
sphinx : None
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : None
pymysql : None
psycopg2 : 2.8.5 (dt dec pq3 ext lo64)
jinja2 : 2.10.3
IPython : 7.10.2
pandas_datareader: None
bs4 : None
bottleneck : None
fastparquet : 0.3.2
gcsfs : None
lxml.etree : None
matplotlib : 3.1.2
numexpr : None
odfpy : None
openpyxl : 3.0.3
pandas_gbq : None
pyarrow : 0.17.0
pytables : None
pytest : None
pyxlsb : None
s3fs : None
scipy : 1.4.1
sqlalchemy : 1.3.13
tables : None
tabulate : 0.8.6
xarray : None
xlrd : 1.2.0
xlwt : None
xlsxwriter : None
numba : 0.46.0

[MarcoGorelli]

Thanks @RauliRuohonen - is this the same as #28104 ?

[RauliRuohonen]

AFAICS that one involves pd.Period and does not involve iloc, whereas this one involves iloc and does not involve pd.Period. Seems different to me, but then again, they might be related at a deeper level.

#26853 suggests that out of bounds datetime handling is not very consistent in general.

[TomAugspurger]

@RauliRuohonen can you try on master? Seems to be working for me.

[RauliRuohonen]

Ach, it does work on current master. Bisecting, it works on dafec63 but not on 9e69040, so it was fixed by the dafec63 commit (PR #32089).

Incidentally, the commit adds a still-present line to whatsnew referring to AFAICS an unrelated PR #32809, which looks like a typo of #32089 (just happened to spot this while checking if there was an issue related to this instead of just a PR).

Sorry for the noise.

[TomAugspurger]

Thanks for confirming where it was fixed.

I think the whatsnew is related. datetime.datetime objects can hold larger values than Timestamp. @RauliRuohonen if you're interested you could amend the release note saying that this fix may avoid OUtOfBoundsDatetime exceptions.