Inclusive Duration Interval

One issue I have run into using NodaTime is that the duration of an interval is from the number of ticks in the interval, rather than the number of ticks in the interval plus one.

For example, if I had an interval whose start was the first tick of May 22nd, 2020, and whose end was the last tick of May 22nd, 2020, then the duration of that interval would not be equal to Duration.FromDays(1); it would be equal to Duration.FromDays(1) - Duration.Epsilon. In this case, I would likely want the duration from the beginning of the first tick to the end of the last tick, rather than the number of ticks.

Is there a design reason for this? Is there motivation to add something like Interval.DurationInclusive?

[jskeet]

your description above implies that an instant has a duration of 1ns

No, an instant doesn’t have a duration. But if an interval contains an instant, it logically means it contains every point in time from that instant up (but not including) the next representable instant.

Given this, wouldn’t it be more consistent and semantically sensible for the inclusivity of the starting instant of Interval to supersede the exclusivity of the ending instant, rather than the other way around?

No, because that’s not how empty intervals work in maths. An empty interval is precisely that: empty. Meaning it doesn’t contain anything.

The current behavior of empty intervals achieves all kinds of mathematical consistencies that would be violated if [a, a) were deemed to include a. For example, the duration of an interval in nanoseconds is exactly matched by "the number of distinct Instant values where interval.Contains(instant). With your proposal, that would be violated by the empty interval (which would have a duration of 0ns, but contain 1 instant). Thinking of an interval as a set, you’re effectively saying that [a, a) should have the same containment predicate as [a, a+1) - namely to include a and only a.

Closing again, as the design is as intended and follows normal maths.

[jskeet]

What Malcolm said, basically. Another way of thinking about it is to consider an empty interval. Consider this:

Instant instant = ...; // It doesn't matter
Interval empty = new Interval(instant, instant);

That starts and ends at the same instant, and has a duration of 0. If we made it include instant, then it should have a duration of 1ns, because it would include that instant and no other.

Another way of thinking about it is to consider arrays. If you create an array like this:

int[] values = new int[5];

… then it has a length of 5, and contains elements 0, 1, 2, 3 and 4. It doesn’t have an element 5. In the same way, if you create an interval of x to x.PlusNanoseconds(5) it includes xns, x+1ns, x+2ns, x+3ns and x+4ns, but not x+5ns.

Basically it sounds like you should be constructing your intervals bearing in mind that the end is exclusive - so don’t build an interval with an end point of “the last tick of 2020-05-22”. In fact, this provides an example of another good reason for being half-open. What is "the last tick of 2020-05-22? Is it 2020-05-22T23:59:59.999999900? If so, the last 99 nanoseconds would be missing even if we included the nanosecond you specified. By expression the end point in terms of “the instant at which the interval ends” rather than “the final instant in the interval”, the precision used is unimportant.