Ihor Radchenko <yanta...@posteo.net> writes:

> The question is: does iCalendar allow something like
> DTSTART;TZID=America/New_York:19970105T083000
> DUE;TZID=America/New_York:20070105T083000
> and repeats past DUE?
> If not, we have to choose when exporting from Org source - either to
> keep DUE or not.

>From the defintion of RRULE [1]: 

      If the duration of the recurring component is specified with the
      "DTEND" or "DUE" property, then the same exact duration will apply
      to all the members of the generated recurrence set.

So the RRULE applies to both DTSTART and DUE, and the repeats continue
past DUE.

But, another thing to note from the definition of DTSTART [2]:

      This property [DTSTART] is REQUIRED in all types of recurring
      calendar components that specify the "RRULE" property.

So technically, a standalone DEADLINE + repeater isn't allowed -- a
repeating task must always have a start date.

But my impression is that not all iCalendar programs respect this. In
particular, Tasks.org app with Nextcloud server seemed to allow a
standalone repeating deadline. But I will check this more carefully, and
also in a couple more programs (radicale, Evolution).

But still, maybe we should stick to the requirement, and only export
repeater on SCHEDULED. That would simplify the implementation. The
downside is that repeating deadlines won't show up in iCalendar, which
seems undesirable.

[1] https://www.rfc-editor.org/rfc/rfc5545#section-
[2] https://www.rfc-editor.org/rfc/rfc5545#section-

> If we want to leave as many options as possible to the users, we can (1)
> Implement ICALENAR_DUE property that will set DUE explicitly on export;
> (2) ICALENDAR_DUE may allow special values that will indicate how to
> treat Org DEADLINEs - make them into DUE, use Org DEADLINE as a
> bound for SCHEDULED repeater, or ignore DEADLINE completely.

A couple of these behaviors can already be achieved by customizing
`org-icalendar-use-deadline' (making DUE or ignoring). For using
DEADLINE as a bound, we could potentially add another option for that.

> Is there any reason for this? May we instead export to a single VEVENT
> with appropriate RDATE list?

I guess if there are multiple timestamps with repeaters, it's easier to
export these as separate VEVENT, because it's not possible to have
multiple RRULE in one VEVENT.

But, your suggestion earlier in thread could also solve this: in case of
different repeaters, we can use RDATE to generate occurrences manually
sufficiently far into future (with defcustom for "how far").

Reply via email to