Boundaries

[brendt]

Adding boundary support, based on what we discussed in #9.

You'll notice that the default behaviour is "both boundaries included". This might not be everyone's preferred default. I heard the arguments pro and con in #9, but am still convinced that all inclusive is the right default behaviour as long as you're comparing periods with the same accuracy.

We could always add sub classes of Period if desired, with other defaults.

I'll leave this PR open for a while, to see what people think.

For those interested, I wrote down why I think working with precision instead of excluding boundaries is the superior approach: https://stitcher.io/blog/comparing-dates

[brendt]

I believe the discrete unit approach is the correct one for this package. Only allowing same-precision periods to be compared, the open/closed boundary problem becomes obsolete.

We'll keep the boundary functionality, but I've also added precision support.

[MrWeb]

If I say "hey! We have a discount from 1st Dec to 31st" I would think day 1 and 31 are included. I don't get the point of excluding them.

[freekmurze]

If you’d say: “hey! We are open from 9:00 to 18:00” Would you close shop at 18:00 or 18:01?

[MrWeb]

If you’d say: “hey! We are open from 9:00 to 18:00” Would you close shop at 18:00 or 18:01?

Right, in both mine and your case 31st and 18 are anyways inside the boundaries, aren't they?

[brendt]

Since no one raised any objections to this implementation, I'm going to merge the PR.