From: "Brent Pinkney" <brent.pinkney at aircom.co.za>
> On Mon, 23 Feb 2004 00:11:56 -0800, Avi Bryant <avi at beta4.com> wrote:
> > I'm not sure what you're saying here.  Is it that this is "unexpected"
> > (to a user), but correct behavior?  Or that the behavior of the code is
> > not what you intended for it to be?
> Mmm, basically the english use is ambiguous, if I am correct the
> mathematical interpretaion/notation of the expression '1pm to 2pm' is
> [1pm..2pm).
>
> Because computer time is discrete and timespan do not overlap, 2pm is not
> the end of the timespan but the start of the next. The end of the timespan
> must therefore be one tick (nanoSecond) previous.

Hmmmm. I'm not sure what exactly it means when you say that "computer time
is discrete", or if it even matters. I am pretty sure, though, that
nanoseconds are arbitrary.

> The alternative leads to overlapping timespans - a big no no.

I agree that you don't want the default interpretations of the timespans
denoted by "1pm to 2pm" and "2pm and 3 pm" to overlap. You don't want any
moment to be part of both. You also don't want any moment to fall in between
the two. Seeing it as [1pm..2pm), as you suggest, makes sense.

I strongly disagree that that is the alternative.

There is a third alternative: doing just as your mathematical notation,
i.e., knowing if the bounds are inclusive or exclusive. A Timespan is
described by two moments, its startmoment and its endmoment, *plus* the
knowledge for each moment whether it is included.

Constructors might look like:

Timespan fromInclusive: startMoment toExclusive: endMoment
Timespan fromExclusive: startMoment toExclusive: endMoment
Timespan fromExclusive: startMoment toInclusive: endMoment

With your default of:

Timespan from: startMoment to: endMoment
^self fromInclusive: startMoment toExclusive: endMoment

There are several reasonable options for implementing this. To hack it,
Timespan could receive two extra instvars (isStartMomentInclusive
isEndMomentInclusive). Or to do it nice, one could use boundary objects that
hold a moment and know if they are inclusive or not (using two classes of
boundary seems to make sense).

> I did agonise over this as well.

Does this help at all?

Cheers,

Peter

> Brent