Context
Per draft-ietf-calext-jscalendar-icalendar-22, RDATE and EXDATE properties should be represented as entries in recurrenceOverrides:
- RDATE values become keys in
recurrenceOverrides with an empty PatchObject (indicating the occurrence exists with no property changes)
- EXDATE values become keys in
recurrenceOverrides with { "excluded": true }
This is how JSCalendar unifies the three iCalendar recurrence-modification mechanisms (RDATE, EXDATE, RECURRENCE-ID overrides) into a single recurrenceOverrides map.
Current behaviour
RDATE and EXDATE are preserved as flat lists (rdates and exdates fields) on the entry record. This is a direct transliteration of the iCalendar structure rather than a semantic translation.
Expected behaviour
RDATE and EXDATE values should be merged into a recurrence_overrides map alongside any RECURRENCE-ID overrides (see #RECURRENCE-ID issue). This may depend on or be done together with the RECURRENCE-ID grouping work.
Context
Per draft-ietf-calext-jscalendar-icalendar-22, RDATE and EXDATE properties should be represented as entries in
recurrenceOverrides:recurrenceOverrideswith an empty PatchObject (indicating the occurrence exists with no property changes)recurrenceOverrideswith{ "excluded": true }This is how JSCalendar unifies the three iCalendar recurrence-modification mechanisms (RDATE, EXDATE, RECURRENCE-ID overrides) into a single
recurrenceOverridesmap.Current behaviour
RDATE and EXDATE are preserved as flat lists (
rdatesandexdatesfields) on the entry record. This is a direct transliteration of the iCalendar structure rather than a semantic translation.Expected behaviour
RDATE and EXDATE values should be merged into a
recurrence_overridesmap alongside any RECURRENCE-ID overrides (see #RECURRENCE-ID issue). This may depend on or be done together with the RECURRENCE-ID grouping work.