handle upper_inc = false ?

[samlll42-github]

Hi thanks for this awesome library.

I am porting part of a python project in rust, which uses the python spans library.

Is there plans to support the equivalent of upper_inc=false (i.e don't include the upper limit)

e.g:

let slot: DateTimeSpan<Utc> = "2019-01-01T15:00:00 +0000 - 2019-01-01T16:00:00 +0000"
    .parse()
    .unwrap();

let t = "2019-01-01T16:00:00 +0000".parse().unwrap();
assert!(!slot.contains(&t));

[fin-ger]

Thanks for filing the first issue :D

Excluding the upper boundary looks like a good addition to this library. I will look into adding this feature!

[fin-ger]

After a quick look into this, I realized this feature must be included in the following functions:

• Span::duration
• Span::difference
• Span::symmetric_difference
• Span::intersection
• Span::union
• Span::contains
• Span::is_disjoint
• Span::is_subset
• Span::is_superset

The above functions basically need a PartialOrd implementation for the start and end markers of the span. One idea would be to respect a upper_boundary and a lower_boundary configuration within a PartialOrd implementation of the start and end markers. This would avoid reimplementing the above functions for every possible configuration. I am not sure how to achieve this. There are two options that come to my mind:

1. Add a wrapper type which implements PartialOrd
2. Add wrapper functions which mimic the behavior of PartialOrd

Any better ideas?

The API of the following functions would need adjustments/extensions:

• Span::split_off: How do we split here? Inclusive or exclusive?
• Span::append: How to move the end marker? Take over boundary configuration of previous end marker? Add a new method append_with_boundary?
• Span::prepend: Same questions as for append
• Span::pop: Same questions as for append
• Span::shift: Same questions as for append

---

I imagine a boundary configuration to look like this:

enum Boundary {
    Inclusive,
    Exclusive,
}

Furthermore, we have to decide how the default boundary configuration should look like. Currently, start and end are both inclusive. However, I think most users would expect the end boundary to be exclusive. Maybe we should break the API with a new release (prior to a 1.0 release) to make a start => Inclusive ; end => Exclusive default configuration.