Don't generate all possible events

[MartinWickman]

Description of the Issue:

Given a recurrence event, it looks like ics-parser generates all possible events during the dates in the ics-file. In my case it creates 10,000 events and takes forever (and uses lots of memory) even though I'm only interested in events for a limited range. Would it be possible to just generate the events for the supplied range instead?

I'm thinking it should be possible to just generate events for the range given in ->eventsFromRange(start, end).

Steps to Reproduce:

BEGIN:VCALENDAR
VERSION:2.0
BEGIN:VEVENT
SUMMARY:Office Hours
DTSTART:19800101T090000
DTEND:19800101T170000
RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE;UNTIL=20180620T215959
DTSTAMP:20180615T132731
UID:6b350fc3c646e59e
END:VEVENT
END:VCALENDAR

$ical->initString($file); // Generates 10,000 events from 1980 until 20180620
$events = $ical->eventsFromRange('2018-06-10 12:00:00', '2018-06-25 17:00:00');

[marcelstoer]

I guess in order to support this the ICAL constructor would need an additional property for a "recurring range". You'd use that one instead of defaultSpan: https://github.com/u01jmg3/ics-parser/blob/master/examples/index.php#L10

[u01jmg3]

Relates to #149

---

I do not think this is as simple as only processing a recurrence event for a desired range (beyond the start and end date defined by the rule). Although this may suit the given rule, other rules can be much more complex and require processing to be started from the beginning (rather than towards the end, 38 years on).

What could be achieved is something similar to the defaultSpan property whereby a user defined (default end) date could be supplied rather than an integer of years (but I think you must always process a recurrence rule from the beginning).

As for the length of time it takes the parser to process your rule in its current version, it takes me 4500ms and comes back with 6,023 events.

The other possibility is to reduce the 38 years of calendar data you have which is only going to grow larger.

[u01jmg3]

Fixed by #190 (#184)