emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Jack Kamm <jackkamm@gmail.com>
To: Ihor Radchenko <yantar92@posteo.net>
Cc: emacs-orgmode@gnu.org, mail@nicolasgoaziou.fr
Subject: Re: [RFC] ox-icalendar: Unscheduled tasks & repeating tasks
Date: Fri, 14 Apr 2023 20:13:13 -0700	[thread overview]
Message-ID: <87wn2d4z3q.fsf@gmail.com> (raw)
In-Reply-To: <87o7nql2sq.fsf@localhost>

Ihor Radchenko <yantar92@posteo.net> writes:

> The question is: does iCalendar allow something like
>
> DTSTART;TZID=America/New_York:19970105T083000
> RRULE:FREQ=YEARLY
> 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-3.8.5.3:
[2] https://www.rfc-editor.org/rfc/rfc5545#section-3.8.2.4

> 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	other threads:[~2023-04-15  3:14 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-26 18:56 [RFC] ox-icalendar: Unscheduled tasks & repeating tasks Jack Kamm
2023-03-27 11:59 ` Ihor Radchenko
2023-03-31  5:55   ` Jack Kamm
2023-03-31 13:07     ` Ihor Radchenko
2023-03-31 15:50       ` Jack Kamm
2023-03-31 17:51         ` Ihor Radchenko
2023-03-31 22:20           ` Jack Kamm
2023-04-01  8:30             ` Ihor Radchenko
2023-04-02  0:47               ` Jack Kamm
2023-04-02  8:48                 ` Ihor Radchenko
2023-04-02 15:34                   ` Jack Kamm
2023-04-02 16:32                     ` Ihor Radchenko
2023-04-14 16:57   ` Jack Kamm
2023-04-14 18:46     ` Ihor Radchenko
2023-04-15  3:13       ` Jack Kamm [this message]
2023-04-15  9:56         ` Ihor Radchenko
2023-04-16 17:19           ` Jack Kamm
2023-06-11 15:35   ` [PATCH] " Jack Kamm
2023-06-12 10:36     ` Ihor Radchenko
2023-06-17 17:32       ` Jack Kamm
2023-06-18 11:28         ` Ihor Radchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wn2d4z3q.fsf@gmail.com \
    --to=jackkamm@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=mail@nicolasgoaziou.fr \
    --cc=yantar92@posteo.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).