BUG: AmbiguousTimeError when using date_range even when argument ambiguous is set

[aleisun]

• 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.

---

Note: Please read this guide detailing how to provide the necessary information for us to reproduce your bug.

Code Sample, a copy-pastable example

>>> import pandas as pd
>>> timezone = 'America/New_York'
>>> start = pd.Timestamp(year=2020, month=11, day=1, hour=1).tz_localize(timezone, ambiguous=False)
>>> pd.date_range(start, periods=2, ambiguous=False)

---------------------------------------------------------------------------
AmbiguousTimeError                        Traceback (most recent call last)
<ipython-input-5-d142fd70e406> in <module>
      2 timezone = 'America/New_York'
      3 start = pd.Timestamp(year=2020, month=11, day=1, hour=1).tz_localize(timezone, ambiguous=False)
----> 4 pd.date_range(start, periods=2, ambiguous=False)

~/anaconda3/envs/oids_tst/lib/python3.6/site-packages/pandas/core/indexes/datetimes.py in date_range(start, end, periods, freq, tz, normalize, name, closed, **kwargs)
   1178         normalize=normalize,
   1179         closed=closed,
-> 1180         **kwargs,
   1181     )
   1182     return DatetimeIndex._simple_new(dtarr, tz=dtarr.tz, freq=dtarr.freq, name=name)

~/anaconda3/envs/oids_tst/lib/python3.6/site-packages/pandas/core/arrays/datetimes.py in _generate_range(cls, start, end, periods, freq, tz, normalize, ambiguous, nonexistent, closed)
    419                 # start/end as well to compare
    420                 if start is not None:
--> 421                     start = start.tz_localize(tz).asm8
    422                 if end is not None:
    423                     end = end.tz_localize(tz).asm8

pandas/_libs/tslibs/timestamps.pyx in pandas._libs.tslibs.timestamps.Timestamp.tz_localize()

pandas/_libs/tslibs/tzconversion.pyx in pandas._libs.tslibs.tzconversion.tz_localize_to_utc()

AmbiguousTimeError: Cannot infer dst time from 2020-11-01 01:00:00, try using the 'ambiguous' argument

Problem description

When the start time is at the day light saving ambiguous time, date_range raises errors even when the argument 'ambiguous' is set. It should not be raising error when the argument is set.

Issue could be due to the line

pandas/pandas/core/arrays/datetimes.py

Line 421 in 32ed15d

start = start.tz_localize(tz).asm8

does not correctly pass the argument ambiguous to the function tz_localize().

Expected Output

No error

Output of pd.show_versions()

AmbiguousTimeError: Cannot infer dst time from 2020-11-01 01:00:00, try using the 'ambiguous' argument

[arw2019]

Confirming that this exists on pandas 1.1 master

Output of pd.show_versions()

INSTALLED VERSIONS

commit : 54db0b2
python : 3.8.3.final.0
python-bits : 64
OS : Linux
OS-release : 5.4.0-40-generic
Version : #44-Ubuntu SMP Tue Jun 23 00:01:04 UTC 2020
machine : x86_64
processor :
byteorder : little
LC_ALL : C.UTF-8
LANG : C.UTF-8
LOCALE : en_US.UTF-8

pandas : 1.1.0.dev0+2130.g54db0b2c7
numpy : 1.18.5
pytz : 2020.1
dateutil : 2.8.1
pip : 20.1.1
setuptools : 49.1.0.post20200704
Cython : 0.29.21
pytest : 5.4.3
hypothesis : 5.19.0
sphinx : 3.1.1
blosc : None
feather : None
xlsxwriter : 1.2.9
lxml.etree : 4.5.2
html5lib : 1.1
pymysql : None
psycopg2 : None
jinja2 : 2.11.2
IPython : 7.16.1
pandas_datareader: None
bs4 : 4.9.1
bottleneck : 1.3.2
fsspec : 0.7.4
fastparquet : 0.4.0
gcsfs : 0.6.2
matplotlib : 3.2.2
numexpr : 2.7.1
odfpy : None
openpyxl : 3.0.4
pandas_gbq : None
pyarrow : 0.17.1
pytables : None
pyxlsb : None
s3fs : 0.4.2
scipy : 1.5.0
sqlalchemy : 1.3.18
tables : 3.6.1
tabulate : 0.8.7
xarray : 0.15.1
xlrd : 1.2.0
xlwt : 1.3.0
numba : 0.50.1

[arw2019]

@aleisun Well spotted! Passing ambigious in lines 421 and 423 of pandas/pandas/core/arrays/datetimes.py seems to fix things. I'll take this and do a PR

[sinan-ozel]

I know that this is issue is closed. But the fact that this bug was reported with such precision, and was resolved swiftly, saved my work day, two years down the line, on a Friday.

Just wanted to remind that open source collaboration makes the world a better place in ways that we do not see day to day.