Skip to content

handle DST appropriately in Timestamp.replace #18618

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.

Sign up for GitHub

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 16 commits into from
Jan 5, 2018
Merged

handle DST appropriately in Timestamp.replace #18618

Changes from 1 commit
Commits
Show all changes
16 commits
Select commit Hold shift + click to select a range
cfb760c
handle DST appropriately in Timestamp.replace
jbrockmendel Dec 4, 2017
4ca60fd
better comment, move test to test_timezones
jbrockmendel Dec 4, 2017
f738989
informative comment in test
jbrockmendel Dec 5, 2017
98a7296
Merge branch 'master' of https://github.com/pandas-dev/pandas into re…
jbrockmendel Dec 6, 2017
6f36a97
handle DST appropriately in Timestamp.replace
jbrockmendel Dec 4, 2017
b916b17
better comment, move test to test_timezones
jbrockmendel Dec 4, 2017
b00d763
informative comment in test
jbrockmendel Dec 5, 2017
000f6cd
Merge branch 'master' of https://github.com/pandas-dev/pandas into re…
jbrockmendel Dec 6, 2017
ec9b38a
Merge branch 'replace_bug' of https://github.com/jbrockmendel/pandas …
jbrockmendel Dec 6, 2017
f5886e2
Merge branch 'master' of https://github.com/pandas-dev/pandas into re…
jbrockmendel Dec 7, 2017
4cfd949
fix duplicate whatsnews caused by merge mixups
jbrockmendel Dec 7, 2017
a3b14f9
Merge branch 'master' of https://github.com/pandas-dev/pandas into re…
jbrockmendel Dec 14, 2017
504cf97
Merge branch 'master' of https://github.com/pandas-dev/pandas into re…
jbrockmendel Dec 29, 2017
4459c9f
fixup merge messup
jbrockmendel Dec 29, 2017
1eb5f2f
Merge branch 'master' of https://github.com/pandas-dev/pandas into re…
jbrockmendel Dec 30, 2017
dced361
refactor test to apply to both pytz and dateutil
jbrockmendel Jan 4, 2018
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
Prev Previous commit
Next Next commit
informative comment in test
  • Loading branch information
@jbrockmendel
jbrockmendel committed Dec 5, 2017
commit f7389898a62aa0cf79b2fbc252fb884fdbb16f41
3 changes: 2 additions & 1 deletion pandas/tests/tseries/test_timezones.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1230,7 +1230,8 @@ def f():
assert dt.tz_localize(None) == dt.replace(tzinfo=None)

def test_replace_across_dst(self):
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 tests with dateutil as well

Copy link
Member Author

Choose a reason for hiding this comment

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

The test is pretty specific to pytz API

Copy link
Contributor

Choose a reason for hiding this comment

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

The test is specific to the pytz API because the problem is specific to the pytz API, so you can't write tests that currently fail with dateutil, but you can, in fact, write this test to be agnostic as to whether the test takes a pytz or dateutil zone.

Rather than using localize and normalize, express the "expected" datetimes as UTC datetimes and use .astimezone. pytz and dateutil support astimezone (and, in fact, pytz.normalize essentially just uses .astimezone under the hood). Since pandas provides their own API layer on top of datetime, it is also agnostic to the timezone provider.

Copy link
Member Author

Choose a reason for hiding this comment

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

Rather than using localize and normalize, express the "expected" datetimes as UTC datetimes and use .astimezone

Is this a suggestion for this test or more generally?

Copy link
Contributor

Choose a reason for hiding this comment

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

Is this a suggestion for this test or more generally?

In this test at least, since with tests you can always engineer your datetime literals such that you never have to use anything except astimezone.

It's also just a useful piece of information to have, that astimezone is one of the few timezone functions where pytz behaves more or less nicely. You only need normalize semantics with pytz for things like replace or "calendar" arithmetic, where you want to change the naive portion of the datetime to a specific value and then change the time zone offset to match. If you want "absolute" arithmetic (where you want to go forward a certain number of hours or seconds or something), then the_operation(dt.astimezone(UTC)).astimezone(dt.tzinfo) will always give the right answer.

In this case you know what the correct answer should be, in absolute time, so you can just declare your initial variable as the correct answer in UTC and convert that to the time zone you care about. If you do it generically like that, you are insulated from any weird quirks of pytz's interface, and you get dateutil support for free (so you can parametrize this test using pytz and dateutil zones).

Of course, this method will fail if you try to construct an imaginary time, since there is no mapping between UTC and imaginary times.

# GH#18319
# GH#18319 check that 1) timezone is correctly normalized and
# 2) that hour is not incorrectly changed by this normalization
tz = pytz.timezone('US/Eastern')

ts_naive = Timestamp('2017-12-03 16:03:30')
Expand Down