FA-77299 / Calendar recurrence rules / Member archive

Re-keying instance overrides after a series start or interval change: instance check · case 04

An override for a date before the series start survives the edit as a phantom exception.

Member previewVariant 4 · 3 implementations · 8 checks per implementation

Case contract

An all-day series (old_start, interval, count) is edited to start at new_start with new_interval. Each override [original, target] (target None = cancelled) is keyed by occurrence index i, where original = old_start + i*interval; overrides not on an old instance (before the series, misaligned or at i >= count) are dropped. The override is re-keyed to new_start + i*new_interval; moved targets are absolute and kept unchanged; an override whose target equals its new key is dropped as a no-op; the last override for a key wins. Return [[new_key, target]] sorted by new key.

Why this case matters

Recurring calendar series are expanded into concrete instances for display, reminders and conflict checks.

One recorded failure

Sample boundary fixture

This sample comes from the broken implementation of a controlled reproducer.

Boundary fixture	Actual	Expected	Outcome
regression: override before series start	`[["2024-01-03", null], ["2024-01-17", "2024-01-20"]]`	`[["2024-01-17", "2024-01-20"]]`	Failed

MEMBER ARCHIVE

The complete case is available to members.

This record includes three runnable implementations, regression fixtures, execution results, and source hashes.

Member access is invitation-based. Sign in with your invited account to inspect the sources.