Skip to content

BUG: Fix Timestamp constructor changes value on ambiguous DST #30995

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions doc/source/whatsnew/v1.1.0.rst
Original file line number Diff line number Diff line change
Expand Up @@ -59,6 +59,7 @@ Categorical

Datetimelike
^^^^^^^^^^^^
- Bug in :class:`Timestamp` where constructing :class:`Timestamp` from ambiguous epoch time and calling constructor again changed :meth:`Timestamp.value` property (:issue:`24329`)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved to whatsnew for v1.1.0

-
-

Expand Down
10 changes: 9 additions & 1 deletion pandas/_libs/tslibs/conversion.pyx
Original file line number Diff line number Diff line change
Expand Up @@ -29,7 +29,7 @@ from pandas._libs.tslibs.util cimport (
from pandas._libs.tslibs.timedeltas cimport cast_from_unit
from pandas._libs.tslibs.timezones cimport (
is_utc, is_tzlocal, is_fixed_offset, get_utcoffset, get_dst_info,
get_timezone, maybe_get_tz, tz_compare)
get_timezone, maybe_get_tz, tz_compare, treat_tz_as_dateutil)
from pandas._libs.tslibs.timezones import UTC
from pandas._libs.tslibs.parsing import parse_datetime_string

Expand Down Expand Up @@ -362,6 +362,14 @@ cdef _TSObject convert_datetime_to_tsobject(datetime ts, object tz,
obj.tzinfo = tz
else:
obj.value = pydatetime_to_dt64(ts, &obj.dts)
# GH 24329 When datetime is ambiguous,
# pydatetime_to_dt64 doesn't take DST into account
# but with dateutil timezone, get_utcoffset does
# so we need to correct for it
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a comment explaining the reasoning for this solution. Tried to make it as brief as possible.

if treat_tz_as_dateutil(ts.tzinfo):
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mroeschke Switched to treat_tz_as_dateutil. Much cleaner now, thank you.

if ts.tzinfo.is_ambiguous(ts):
dst_offset = ts.tzinfo.dst(ts)
obj.value += int(dst_offset.total_seconds() * 1e9)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because pydatetime_to_dt64 doesn't take DST into account but get_utcoffset does, we need to add the DST timedelta to the result of pydatetime_to_dt64. This is necessary only for dateutil, because for ambiguous dates pytz immediately switches off DST and reduces UTC offset, so no correction is necessary for pytz timezones.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you add a comment to this effect here

obj.tzinfo = ts.tzinfo

if obj.tzinfo is not None and not is_utc(obj.tzinfo):
Expand Down
8 changes: 1 addition & 7 deletions pandas/tests/indexes/datetimes/test_timezones.py
Original file line number Diff line number Diff line change
Expand Up @@ -573,13 +573,7 @@ def test_dti_construction_ambiguous_endpoint(self, tz):
"2013-10-26 23:00", "2013-10-27 01:00", freq="H", tz=tz, ambiguous="infer"
)
assert times[0] == Timestamp("2013-10-26 23:00", tz=tz, freq="H")

if str(tz).startswith("dateutil"):
# fixed ambiguous behavior
# see GH#14621
assert times[-1] == Timestamp("2013-10-27 01:00:00+0100", tz=tz, freq="H")
else:
assert times[-1] == Timestamp("2013-10-27 01:00:00+0000", tz=tz, freq="H")
assert times[-1] == Timestamp("2013-10-27 01:00:00+0000", tz=tz, freq="H")
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now no matter whether we use dateutil or pytz timezones, we get the same date range, so separate testing conditions are no longer necessary.


@pytest.mark.parametrize(
"tz, option, expected",
Expand Down
11 changes: 11 additions & 0 deletions pandas/tests/scalar/timestamp/test_timestamp.py
Original file line number Diff line number Diff line change
Expand Up @@ -1081,3 +1081,14 @@ def test_dt_subclass_add_timedelta(lh, rh):
result = lh + rh
expected = SubDatetime(2000, 1, 1, 1)
assert result == expected


def test_constructor_ambigous_dst():
# GH 24329
# Make sure that calling Timestamp constructor
# on Timestamp created from ambiguous time
# doesn't change Timestamp.value
ts = Timestamp(1382835600000000000, tz="dateutil/Europe/London")
expected = ts.value
result = Timestamp(ts).value
assert result == expected