By: Tom Sydney Kerckhove <syd@cs-syd.eu>
ical-recurrence: apply a RANGE=THISANDFUTURE override to the instances it covers
Every instance at or after the one a RANGE=THISANDFUTURE override names is
now rescheduled by the difference between that override's DTSTART and the
instance it names, and given that override's duration, which is what the
previous commit's tests asked for.
An instance's own start is its RECURRENCE-ID value, per section 3.8.4.4:
@
Subsequent instances are determined by their "RECURRENCE-ID" value
and not their current scheduled start time.
@
so the override that covers an instance is the last one naming an instance
at or before it, and two overrides do not compose: each measures its
difference from the instance it names rather than from where an earlier
override left that instance. An instance that has an override of its own
is never rescheduled, which is the rest of that paragraph:
@
Subsequent instances
defined in separate components are not impacted by the given
recurrence instance.
@
The difference is an exact duration rather than a nominal one, matching
what section 3.8.5.1 already requires of a DTEND ("the same exact duration
will apply to all the members of the generated recurrence set") and what
'computeNewEnd' already does with it. For a zoned instance that is also
what keeps the wall clock: two hours after 09:00 is 11:00 in whichever
offset the day happens to be in, because 'addExactDuration' resolves and
unresolves through the time zone rather than adding to the local time.
Only the rescheduling and the duration are prescribed. The override's
component comes along with them, because an 'Occurrence' carries the
component whose properties apply to it, and a producer that writes "this
and future" with a changed SUMMARY means that for the range too.
A RECURRENCE-ID, the DTSTART of the component carrying it and the
instances of the series all have to share a value type, so
'ThisAndFutureMismatch' is an unfixable error for input where they do not:
there is no rescheduling to derive from a number of days and a time of
day. This follows 'StartEndMismatch', which the same section's value-type
requirement already made unfixable.