018c40a2

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.

Suite timing

Time to Start Worker time Duration Time to finish Idle
Config 16m08s 1s 1s 16m10s 16m08s
Eval 16m38s 17s 17s 16m56s 28s
Build 16m56s 0s 0s 16m56s 0s
Suite 16m08s 19s 47s 16m56s 16m36s

Timeline

0s16m10s16m40s16m50s