Add utils.within_delta

[pganssle]

Issue to track the datestuff.utils.within_delta utility from the datestuff library. See #431.

@justanr

[justanr]

Had a question about licensing in #431 but doesn't seem like a show stopper assuming my understanding is correct.

[justanr]

Oh, one point I'd like to point out is that within_delta, as written, isn't compatible with relativedelta because timedelta and relativedelta are not comparable.

Edit: If it needs to be, seems like doing diff + relativedelta() would be sufficient for interop Turns out I was wrong, relativedelta doesn't look like it is comparable to itself either.

[pganssle]

@justanr With regards to licensing, nothing special needs to be done just because the code exists in another repo. You don't have to "relicense" the other code in any way because you own it and are welcome to offer it on different license terms in different formats, etc.

That said, I've always been somewhat uncertain about how automatic the licensing is with Github PRs. I guess the idea is that if you make a PR and the repo has the LICENSE file, you're releasing your changes under that license, so a normal PR should be sufficient.

At some point I'll look into changing the LICENSE file to add "Contributors" or something so it's clear that we (the maintainers) are not claiming to own the copyright of all contributions. I'll have to see what other projects do. Either way, if there's any legal issue with you making a normal PR then I have the same problem with all contributors, so there's nothing special about this situation ;)

[pganssle]

Regarding relativedelta, I wouldn't want to open that can of worms. relativedelta is not entirely the same as an interval of time, and even the parts of it that do represent intervals aim to do so in civil time, which does not obey many basic arithmetic properties you'd expect like transitivity of addition and subtraction, so I think this is very much a "buyer beware" situation, no need to go out of our way to support it in this case.