You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Tracking it down, it appears that the problem is that _get_range_edges carries the time over when downsampling intraday data. So when generate_range is called during the DatetimeIndex creation, the final bin doesn't pass the while cur <= end check.
Thinking about it, there are two issues.
generate_range should never output an index that doesn't include end. Maybe something
whileTrue:
yieldcur# last ifcur>=end:
break
_generate_range_edges should generate a range that is perfectly divisible by the freq. For the downsampling, we'd have to change the time by adjusting the end time or just zeroing both out. I don't know how many rely on this behavior though.
The text was updated successfully, but these errors were encountered:
I think that any non-"Tick" offsets, (e.g. AS-DEC as you're doing there) should zero-out the start and end times. This fixes your test case-- all the other tests pass and I haven't thought through the ways this could cause other bugs (hopefully None). Your #1 point is one way to look at it-- when I thought about the date range API initially, I felt that the start and end times should be strict, with no dates generated outside them (roll forward start / roll back end). Requiring that the range include both endpoints is the other way (roll back start, roll forward end). Would be a difficult to change now...
Simple Example
Long example:
http://nbviewer.maxdrawdown.com/3344040/intraday%20binning%20error.ipynb
Tracking it down, it appears that the problem is that
_get_range_edges
carries the time over when downsampling intraday data. So whengenerate_range
is called during theDatetimeIndex
creation, the final bin doesn't pass thewhile cur <= end
check.Thinking about it, there are two issues.
generate_range
should never output an index that doesn't include end. Maybe something_generate_range_edges
should generate a range that is perfectly divisible by the freq. For the downsampling, we'd have to change the time by adjusting the end time or just zeroing both out. I don't know how many rely on this behavior though.The text was updated successfully, but these errors were encountered: