#77 Support for Open and Closed Intervals

[Anonymous]

The base interface for ReadableInterval specifies a semi-open interval (i.e. the range includes the start time but not the end time). This seems like an arbitrary distinction, that doesn't always mesh with what the user needs.

This makes it difficult to implement a closed interval without violating the implied contract defined by the ReadableInterval interface. It would be prefereable to have a GenericInterval interface which could be open or closed, and then multiple implementations defining the exact nature of the interval.

Fully closed (and fully open) intervals would be a nice addition to the API.

Something like the following:

    GenericInterval interval;
    //It would be nice to have an implementation that is closed
    interval = new ClosedInterval(new DateTime(2010, 01, 01, 00, 00), new DateTime(2010, 12, 31, 00, 00));

    assertTrue(interval.contains(new DateTime(2010, 12, 31, 00, 00)));

[Stephen Colebourne]

While I sometimes see the need for intervals other than open-closed, it always seems rare. The main use cases are around dates (without times) which would be better dealt with by a LocalDateInterval class.

To set expectations, I don't plan to add fully controlled intervals to Joda-Time. But GitHub is available for forking ;-)

[Anonymous]

I agree with your assertion that it's not necessarily something that should be included into the core of JODA time, but I might suggest altering the documentation in such a way that ReadableInterval doesn't enforce all of its implementations will be of a open-closed form.

For example, for those of us who do need such functionality, it would be nice to implement it as an implementation of ReadableInterval, but doing so now violates the contract imposed by ReadableInterval. Looking through the code, I don't think there is any reason why all ReadableIntervals must be of the open-closed nature, it seems like that sort of decision could be deferred to the implementations of the interface.

[Stephen Colebourne]

I'd be reluctant to change the meaning of the methods, simply because it is indirectly a backwards incompatible change (users may have made assumptions based on the javadoc).

I don't see any reason why your application cannot implement the interface provided that all your usages are checked - just declare it as a non-conformant implementation.