Do not convert series when looking at sub-daily frequencies. #8782
Conversation
| @@ -712,10 +712,18 @@ def __init__(self, index, warn=True): | |||
| @cache_readonly | |||
| def deltas(self): | |||
| return tslib.unique_deltas(self.values) | |||
|
|
|||
| @cache_readonly | |||
| def deltas_original(self): | |||
There was a problem hiding this comment.
maybe name these deltas_i8 (or deltas_underlying), and similarly for unique.
|
pls add a release note, minor corrections, otherwise looks good |
|
cc @ischwabacher you happy with this? any other tests needed? |
| self.assertEqual(index.inferred_freq, "3H") | ||
|
|
||
| index = date_range("2014-10-25 03:00", periods=5, freq="10H", tz="Europe/Paris") | ||
| self.assertEqual(index.inferred_freq, "10H") |
There was a problem hiding this comment.
Maybe add this:
index = date_range("2013-11-03", periods=5, freq="3H").tz_localize("America/Chicago")
self.assertIsNone(index.inferred_freq)
|
Otherwise LGTM. |
|
I am going to add more tests over both DST transitions (fall and spring) and then some more granular frequencies. This is why we are in the trouble we are in for all the DST issues...the tests don't cover the transitions. I can add that new one as well. Will be later this evening. Thanks. |
|
Yeah, I've started using ranges including 2013-11-03 or 2014-03-09 as interactive test cases whenever I start to mock up some new feature involving times in ipython. Which occasionally leads me to think "oh, I can't do that" when the problem is actually "oh, that doesn't work over a DST boundary". Also I really like the approach taken in |
|
@jreback, should be good now. |
|
thanks! |
Fixes #8772 by not converting values from UTC to local timezone when trying to infer sub-daily frequencies. Across a DST transition this will result in a non-unique deltas and an inferred frequency of None.