#1 New functionality and possible fixes

[Dustin]

Currently, iCal4J is a sturdy and direct mapping of the
iCalendar RFC, but provides little extra functionality
such as returning date ranges and the like. Included
in this patch are:

Added two classes:
net.fortuna.ical4j.model.DateRange
net.fortuna.ical4j.util.DateRangeNormalizer

1. Give the Calendar object the ability to return the
Date Ranges represented by its recurring VEvents.

2. Give the Recur a new getDates() method that takes
into account the DTSTART and applies it to the query
start date where necessary. See comments in code. All
utility methods associated with it are also supplied.
The weekno variable was also moved a few lines down in
the getAbsWeekDay() method.

Removed the resetting of java.util.Calendar parts of
the start date in the newly provided getDates() method.

3. Give VEvent the ability to return a SortedSet of
Date Ranges, represented as DateRange objects. This
will take into account all EXDATE and EXRULE
properties. With this, VEvent can now also call upon
its Recur property (if present) to get all start dates
for this recurring VEvent. Also added a convenience
methods getStartDate() and getEndDate() which will
return the DtStart and DtEnd respectively.
getEndDate() will take into account the Duration if no
DTEND is found. The funcionality of getEndDate() may
be inaccurate and the methods probably should be
getDtStart() and getDtEnd().

4. All tests updated and runnable.

[Dustin]

ZIP file containing all necessary items and new classes.

[Dustin]

Logged In: YES
user_id=1239202

Forgot to add the new Unit Tests for DateRange and
DateRangeNormalizer.

[Dustin]

DateRange Unit Test

[Dustin]

Unit Test for DateRangeNormalizer

[Dustin]

DateRangeNormalizer Unit Test

[Dustin]

Logged In: YES
user_id=1239202

DateRangeNormalizer Unit Test.

[Ben Fortuna]

Logged In: YES
user_id=14058

Dustin, thanks for this patch - looks good. Just a couple of
points:

Changes to Recur:

* Seeing as your getDates() method only uses the time
(Date) component of the DtStart, could we possibly just pass
this as a java.util.Date (i.e. three dates as arguments:
base, start, end)?

* Would you agree that your getDates() method can actually
replace the existing getDates() method (as a new and
improved version!)? If we go with three Dates as arguments
to the new method we could just replace the existing method
with a call to the new method passing the start date as the
base date. eg:

public final DateList getDates(final Date start, final Date
end, final Value value) {
return getDates(start, start, end, value);
}

Inclusion of DateRange:

I was originally thinking that we could perhaps use the
net.fortuna.ical4j.model.Period for this functionality. It
basically defines a start date and end date/duration, and of
course its a "type" defined in RFC2445.

However, seeing the effort that has gone into the
DateRange/DateRangeNormalizer classs I'm happy to add it as
is. Just wondering what are your thoughts on possible
merging the Period/DateRange at some point in the future?

VEvent.getDateRanges()/Calendar.getEventDateRanges():

This functionality is definitely needed, however I want to
make sure the implementation doesn't diverge too far from
the way VFreeBusy components are created (see
VFreeBusy.createPeriodList()).

What this means is that at some point in the future I'll
probably take your implementations of these methods and
integrate them into the VFreeBusy class. So although these
methods may disappear in the future, its most likely they
have just been moved to stay consistent with an
RFC2445-recommended approach.

Anyway, I've added all of your improvements to the codebase
verbatim for now, thanks again for this. If you disagree
with my points on the similarities between DateRange and
Period (the basis of much of what I've written) then do let
me know.

regards,
ben