Closed
Description
Pretty obscure bug, but this seems fishy:
In [7]: pd.__version__
Out[7]: '0.24.0.dev0+1300.ge0a68076a.dirty'
# Ambiguous time
In [8]: t = pd.Timestamp(1382835600000000000, tz='dateutil/Europe/London')
# Repr is consistent
In [11]: t
Out[11]: Timestamp('2013-10-27 01:00:00+0100', tz='dateutil//usr/share/zoneinfo/Europe/London')
In [12]: pd.Timestamp(t)
Out[12]: Timestamp('2013-10-27 01:00:00+0100', tz='dateutil//usr/share/zoneinfo/Europe/London')
# .value changes
In [13]: t.value
Out[13]: 1382835600000000000
In [14]: pd.Timestamp(t).value
Out[14]: 1382832000000000000
pytz timezones behave consistently though
In [15]: t = pd.Timestamp(1382835600000000000, tz='Europe/London')
In [16]: t
Out[16]: Timestamp('2013-10-27 01:00:00+0000', tz='Europe/London')
In [17]: pd.Timestamp(t)
Out[17]: Timestamp('2013-10-27 01:00:00+0000', tz='Europe/London')
In [18]: t.value
Out[18]: 1382835600000000000
In [19]: pd.Timestamp(t).value
Out[19]: 1382835600000000000
The fact that the repr between dateutil timezones and pytz timezones don't match can be possible be seen in a change in dateutil somewhere around 2.6? But the main issue that is .value
changes.
pandas/pandas/tests/indexes/datetimes/test_timezones.py
Lines 564 to 571 in 216986d