BUG: able to create nonexistent Timestamp

• 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 pandas as pd
ts = pd.Timestamp(year=2001, month=10, day=14, hour=0, minute=30, tz='America/Santiago')
print(ts)

Problem description

There was a DST transition on the 14th of October 2001, and the time from midnight to 1 a.m. does not exist. Ran into this while working on #40517 where we ran into an error while normalizing a Timestamp when midnight does not exist in a particular timezone. Yet, we are able to create this timestamp directly, even though it does not make any sense.

Expected Output

I would expect NonExistentTimeError: 2001-10-14 00:30:00

Notes

I wasn’t able to find a prior issue for this. I’m a bit swamped right now, so I would appreciate if someone else looked at this bug. If no one takes it up, I’ll investigate next week.

Output of pd.show_versions()

This is on my dev environment, but I’m getting the same behavior on the latest stable version.

INSTALLED VERSIONS

commit : 692bba578efb5e305c9b116568e5aad75b3fdbb3 python : 3.8.8.final.0 python-bits : 64 OS : Windows OS-release : 10 Version : 10.0.19041 machine : AMD64 processor : Intel64 Family 6 Model 94 Stepping 3, GenuineIntel byteorder : little LC_ALL : None LANG : en_US.UTF-8 LOCALE : English_United States.1251

pandas : 0.26.0.dev0+6766.g692bba578e numpy : 1.20.1 pytz : 2021.1 dateutil : 2.8.1 pip : 21.0.1 setuptools : 49.6.0.post20210108 Cython : 0.29.22 pytest : 6.2.2 hypothesis : 6.3.4 sphinx : 3.5.1 blosc : None feather : None xlsxwriter : 1.3.7 lxml.etree : 4.6.2 html5lib : 1.1 pymysql : None psycopg2 : None jinja2 : 2.11.3 IPython : 7.21.0 pandas_datareader: None bs4 : 4.9.3 bottleneck : 1.3.2 fsspec : 0.8.7 fastparquet : 0.5.0 gcsfs : 0.7.2 matplotlib : 3.3.4 numexpr : 2.7.2 odfpy : None openpyxl : 3.0.6 pandas_gbq : None pyarrow : 3.0.0 pyxlsb : None s3fs : 0.5.2 scipy : 1.6.0 sqlalchemy : 1.3.23 tables : 3.6.1 tabulate : 0.8.9 xarray : 0.17.0 xlrd : 2.0.1 xlwt : 1.3.0 numba : 0.52.0

[hewittk]

Update: We think that we managed to resolve this issue by making a naive timestamp and then checking it against the user-requested timezone using tz_localize_to_utc_single. We’ll be adding test cases and making a PR soon.

[rauniyars]

Take - Working with my team to contribute to this issue.