Obtaining end time or duration of rrule instances

[mossbauer]

In this example:

DTSTART;TZID=America/Chicago:20160120T060000
DTEND;TZID=America/Chicago:20160120T070000
RRULE:FREQ=WEEKLY;COUNT=10;BYDAY=WE

It seems like using the existing API, we can get a list of start DateTime(s) from RecurrenceRuleIterator.nextDateTime()

However, there is no obvious way to get the end DateTime for each instance. To do that, we would need to either calculate the duration between DTSTART and DTEND manually (is there support for creating a DURATIOn from two DateTime(s)?) or to create two RecurrenceRuleIterators using rRule.iterator(DTSTART) for the first one and rRule.iterator(DTEND) for the second one, then co-iterate them.

Is there a cleaner way to do this? would it be a good idea to return a structure with start,end from RecurrenceRuleIterator.getNextDateTime()

[dmfs]

At present there is no support for deriving a Duration from two DateTimes. It's planned though.
There are a few constraints for this, e.g. unless you create an absolute Duration, both DateTime objects need to be in the same time zone. Otherwise you may get a wrong result if there are any DST changes in any of the time zones.

Right now the best you can do is to get the absolute Duration like so

// watch out: duration objects take seconds, not milliseconds
Duration duration = new Duration(1, 0, Math.abs(dateTime1.getTimestamp() - dateTime2.getTimestamp())/1000);

This will get the absolute Duration between both DateTime objects (which might be different from the local Duration if there is an odd number of DST changes between both dates).

The intended way of getting the end date is indeed to derive the end date from the iterated start by adding the duration like so:

DateTime start = iterator.nextDateTime();
DateTime end = start.addDuration(duration);

As mentioned in #22 we're planning an overhaul of this library to incorporate a couple of new ideas about the architecture and recurrence in general. As a result of this the 1.x releases will not be backwards compatible with the 0.9.x releases, same goes for the datetime lib. So if you use Gradle to pull this in make sure you specify the exact version number instead of "or newer".

[mossbauer]

Thank you, this is already what I did for now, and noted to myself the DST related risks.