Subject: [calsify] RSCALE + splitting recurrence sets

From: Marten Gajda <[email-masked]>
Date: Wed, 15 Oct 2014 17:49:45 +0200

Hi all,

I've come across a problem with RSCALE that doesn't appear to be trivial 
to me. You know that it's common procedure to split an event in two when 
you change "this and all following instances" of a recurring event. 
However, there seem to be some implications when doing that when RSCALE 
is present.
Here is an example:

DTSTART;VALUE=DATE:20120229
RRULE:FREQ=YEARLY;RSCALE=GREGORIAN;SKIP=FORWARD

this event recurs every leap year on the 29th of February and on the 1st 
of March in non-leap years. (I must admit that I'm not sure how many 
clients actually include BYMONTH=2 and BYMONTHDAY=29 in the rule)

Now consider the users chooses to change the title of the event for the 
instance on 2014-03-01 and all following instances. Most (if not all) 
calendar clients would create a new event with the original start date 
and a truncated recurrence rule like this

DTSTART;VALUE=DATE:20120229
RRULE:FREQ=YEARLY;RSCALE=GREGORIAN;SKIP=FORWARD;COUNT=2

or this

DTSTART;VALUE=DATE:20120229
RRULE:FREQ=YEARLY;RSCALE=GREGORIAN;SKIP=FORWARD;UNTIL=20130301

that represents all past instances that didn't change. Then they would 
update the existing event to start at the first updated instance using 
the same rule:

DTSTART;VALUE=DATE:20140301
RRULE:FREQ=YEARLY;RSCALE=GREGORIAN;SKIP=FORWARD

Which is incorrect!

DTSTART;VALUE=DATE:20140229
RRULE:FREQ=YEARLY;RSCALE=GREGORIAN;SKIP=FORWARD

would be incorrect too!

The only solution seems to be to specify BYMONTH and BYMONTHDAY like so

DTSTART;VALUE=DATE:20140301
RRULE:FREQ=YEARLY;RSCALE=GREGORIAN;SKIP=FORWARD;BYMONTH=2;BYMONTHDAY=29

You can create similar cases with calendar scales that have leap months.

However, this kind of conflicts with RFC 5545 
(http://tools.ietf.org/html/rfc5545#section-3.8.5.3) which says:
>        The "DTSTART" property value SHOULD be synchronized with the recurrence rule, if
>        specified.  The recurrence set generated with a "DTSTART" property
>        value not synchronized with the recurrence rule is undefined.
I think the RSCALE specs should mention this case and advise how to deal 
with it. Maybe in a "best practices for creating RRULEs (when using 
RSCALE)" section.

cheers

Marten

-- 
Marten Gajda
Schandauer Straße 34
01309 Dresden
Germany

tel: +49 177 4427167
email: [email-masked]
twitter: twitter.com/dmfs_org

VAT Reg. No.: DE269072391

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 15 Oct 2014 12:09:55 -0400

Hi Marten,

> RRULE:FREQ=YEARLY;RSCALE=GREGORIAN;SKIP=FORWARD;BYMONTH=2;BYMONTHDAY=29

No - a workable alternative for the ongoing event is:

DTSTART;VALUE=DATE:20120229
RRULE:FREQ=YEARLY;RSCALE=GREGORIAN;SKIP=FORWARD
EXDATE;VALUE=DATE:20120229
EXDATE;VALUE=DATE:20130301

i.e., the client has to use a valid yyyy0229 date as the starting point to 
get the correct skip behviour, but it removes the first 1 - 3 instances 
that are not needed.

> You can create similar cases with calendar scales that have leap months.

I haven't thought to hard about that, but I would guess the EXDATE approach 
would work there too. The only downside is that the number of EXDATEs 
needed might grow large. (And yes if we still had EXRULE we could have made 
use of that, but we dumped it when we revised iCalendar in 5545.)

>>        The "DTSTART" property value SHOULD be synchronized with the
>>        recurrence rule, if specified.  The recurrence set generated with
>>        a "DTSTART" property value not synchronized with the recurrence
>>        rule is undefined.

Technically this problem exists for the leap day in regular 5545 RRULEs - 
so it is not specific to RSCALE, but as you note leap months do exacerbate 
it. However, I am not sure what the scope of such a best practices section 
would be as there are probably quite a few other issues with RRULEs that 
people would want described. Perhaps it would be better to leave that for a 
separate IETF BCP (best common practices) document for iCalendar that could 
cover not only RRULEs but other problematic areas like time zones.

-- 
Cyrus Daboo

---

From: Gregory Yakushev <[email-masked]>
Date: Wed, 15 Oct 2014 20:20:18 +0000

Yes, recurrence split is a problem, but as Cyrus says its not specific to
RSCALE. It is a more generic problem: when we do the split by creating a
new recurring event, we also lose event identity. Tail UID will be
different, so anything pointing to instances of the head event will no
longer work, EXCEPTION-IDs and in-flight invites/responses are lost, it is
no longer possible to do changes to the whole series (head+tail) etc.

There's a facility in RFC5545 to handle the split gracefully:
RANGE=THISANDFUTURE.
Internally we already use it for most recurrence splits in Google Calendar,
although we translate it into separate recurrences for CalDAV so not to
confuse existing clients. I think wider adoption of RANGE=THISANDFUTURE by
the industry will be good, although we'd need to nail down some issues
(like a split that changes DTSTART or RRULE).

This work may fall under CalExt working group charter, but definitely lies
outside the scope of the RSCALE draft.

Best Regards
Grisha

On Wed Oct 15 2014 at 6:12:12 PM Cyrus Daboo <[email-masked]> wrote:

> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify
>