span_range and interval return times outside the specified range
See original GitHub issueThe implementation of span_range (and also interval()) is surprising to me, and is not what I would expect from a range function.
>>> start = datetime(2013, 5, 5, 12, 30)
>>> end = datetime(2013, 5, 5, 17, 15)
>>> for r in arrow.Arrow.span_range('hour', start, end):
... print(r)
...
(<Arrow [2013-05-05T12:00:00+00:00]>, <Arrow [2013-05-05T12:59:59.999999+00:00]>)
(<Arrow [2013-05-05T13:00:00+00:00]>, <Arrow [2013-05-05T13:59:59.999999+00:00]>)
(<Arrow [2013-05-05T14:00:00+00:00]>, <Arrow [2013-05-05T14:59:59.999999+00:00]>)
(<Arrow [2013-05-05T15:00:00+00:00]>, <Arrow [2013-05-05T15:59:59.999999+00:00]>)
(<Arrow [2013-05-05T16:00:00+00:00]>, <Arrow [2013-05-05T16:59:59.999999+00:00]>)
(<Arrow [2013-05-05T17:00:00+00:00]>, <Arrow [2013-05-05T17:59:59.999999+00:00]>)
I think the return value should be:
(<Arrow [2013-05-05T12:30:00+00:00]>, <Arrow [2013-05-05T13:29:59.999999+00:00]>)
(<Arrow [2013-05-05T13:30:00+00:00]>, <Arrow [2013-05-05T14:29:59.999999+00:00]>)
(<Arrow [2013-05-05T14:30:00+00:00]>, <Arrow [2013-05-05T15:29:59.999999+00:00]>)
(<Arrow [2013-05-05T15:30:00+00:00]>, <Arrow [2013-05-05T16:29:59.999999+00:00]>)
(<Arrow [2013-05-05T16:30:00+00:00]>, <Arrow [2013-05-05T17:14:59.999999+00:00]>)
The first span should start at the specified start
, and the final span should truncate so as not to extend beyond end
.
I know “span” means something specific (arrow.utcnow().span('day')
) and span_range() makes sense considering that definition, but this function still seems surprising and broken. Perhaps however I’m unaware of a use case for the existing span_range(), and I actually want to write a different function like split_range()?
At the very least, my use case is along the lines of:
start_date = arrow.get('2011-02-01')
end_date = arrow.get('2017-11-24')
for start, end in arrow.Arrow.interval('day', start_date, end_date , max_days_to_sync):
service.syncdata(start, end)
And this breaks when I inadvertently sync data outside the dates I asked for.
I’m happy to submit a pull request or discuss further.
Issue Analytics
- State:
- Created 6 years ago
- Reactions:2
- Comments:9 (3 by maintainers)
Yeah take a look at the existing PRs for sure. It seems like there were some existing edge cases that came up during our manual testing, so the PR was 90% there, but couldn’t get merged in the end.
Hi @egannon you might want to look at the old PR for this (#731), the fix worked bar a few edge cases.
edit: actually #817 was the revamped PR by Jad.