BUG/API: Timestamp(naive_str, tz=tz) vs Timestamp(naive_str).tz_localize(tz)

[jbrockmendel]

dtstr = '11/06/2011 01:00'
tz = "US/Eastern"

>>> pd.Timestamp(dtstr, tz=tz)
Timestamp('2011-11-06 01:00:00-0500', tz='US/Eastern')

>>> pd.Timestamp(dtstr).tz_localize(tz)
pytz.exceptions.AmbiguousTimeError: Cannot infer dst time from 2011-11-06 01:00:00, try using the 'ambiguous' argument

I expected these to be equivalent. Am I wrong to expect that?

Looks like the constructor version goes through _localize_pydatetime (then pytz's tz.localize) instead of Timestamp.tz_localize which apparently doesn't find this case ambiguous.

Update: passing is_dst=None to tz.localize in _localize_pydatetime causes the constructor version to raise like I expected.

Update 2: passing is_dst=None as above breaks two tests in the test suite: test_dti_tz_localize_ambiguous_infer and test_fallback_singular

[jbrockmendel]

@jreback thoughts on the original intention here?

[jbrockmendel]

Discused with @jorisvandenbossche and @mroeschke today on the dev call. Agreed that we expect the constructor to behave like tz_localize. Noted that using ZoneInfo (and probably dateutil) instead of pytz tzinfo has different behavior bc of 'fold' keyword, which we don't handle well in the Timestamp constructor.

[jorisvandenbossche]

Agreed that we expect the constructor to behave like tz_localize

Or that we expect it to honor the fold keyword?