FIX BUG: Stop adding referenceDate to results when at least one RRule is defined

[ITESMEDIA]

We changed a few things based on the following premises:

• The DTSTART of a recurring calendar component must not be included the recurrence set if it does not match the RRule
• Calling RecurrenceUtil.GetOccurrences with the same periodStart and periodEnd must include events that starts at that specific moment
• Calling RecurrenceUtil.GetOccurrences with the same periodStart and periodEnd must not include events that ends at that specific moment

Not adding referenceDate to the results set at the start allows the rest of the logic to run normally and only add that date if it's part of the reccurenceRule. It will still be added to the results if the element has no recurrenceRule defined.

Theses modifications make issue #432 more predictable by returning the same results on the first day and subsequent days which are in the RRule. A slightly modified version of the code provided from that issue has been added to the unit tests.

[BrettBurbidge]

Please approve this change. I am doing some strange (if date != today) stuff to get around this now. Thank you for your contribution.

[bkadhim]

I don't understand this change. I am experimenting with migrating from the Aspose.Email library and this is creating an incompatibility. My reading of the iCal standard is that DTSTART always represents the first occurrence (section 3.3.10):

The "DTSTART" property value always counts as the first occurrence.

Not including makes it more complicated to deal with exclusion rules, because if the exclusion rule happens to include DTSTART, one would expect it to be removed.

[minichma]

Actually dtstart MUST match the first occurrence according to the RFC. If it doesn't, the behavior is undefined. So this change should only cause incompatibilities with calendars that violate the standard.