Subject: [calsify] JSCalendar recurrenceRule until vs. before

From: Robert Stepanek <[email-masked]>
Date: Thu, 14 Feb 2019 17:22:22 +0100

We are considering to change the definition of a JSCalendar recurrence
rule to simplify specifying time-bounded recurrence rules. We'd be happy
about your feedback.
Currently, a JSCalendar recurrenceRule[1] type is almost completely
compatible with an iCalendar RRULE. The only difference is that the
until property of a recurrenceRule is defined as a local time, whereas
in iCalendar it must be a UTC time if DTSTART is a UTC time or a local
time with time zone reference.
We are evaluating if to use a "before" property in JSCalendar
recurrences, instead of "until". This "before" property would time-
bound the recurrence set exclusively, whereas the UNTIL definition in
iCalendar is inclusive. The rationale is that an exclusive "before"
would allow to use the same value as boundary, regardless if the
event is an all-day event. In contrast, using the current inclusive
"until" requires two different values, depending on if the event is
all-day or not.
For example, an all-day recurring event that ends on February 14, 2019
requires the until value to be "2019-02-14T00:00:00". However, if all-
day is false, this would need to be "2019-02-14T23:59:59" to allow for
all inclusive occurrences on that day. An exclusive "before" could in
both cases be "2019-02-15T00:00:00".
This would make semantics of JSCalendar recurrenceRules differ to
iCalendar, and we are wary of the risks involved. Yet, it clearly would
make things simpler. What's your take on this?
Cheers,
Robert

Links:

  1. https://tools.ietf.org/html/draft-ietf-calext-jscalendar-11#section-4.3.1

---

From: Marten Gajda <[email-masked]>
Date: Thu, 14 Feb 2019 18:11:55 +0100

I've never understood why iCalendar specified until to be inclusive in
the first place. However, I also don't see much of a problem either.

If this is really a concern for some of us, there might be another
solution to this approach: Just allow until to have a non-zero time
component, even if all-day is true. This way "until=2019-02-14T23:59:59"
could be used for all-day and non-all-day events.

Conversion to iCalendar RRULE is trivial: just remove the time component

Conversion from iCalendar is trivial too: just append "T23:59:59" to the
until date.

My implementation wouldn't really care. It does check whether until is
all-day if the given start is all-day, but it only does so to enforce
RFC 5545 compliance of the given rule. I could just as well remove that
check and it would still yield the correct result.

In any case such a change certainly wouldn't require more changes on the
rrule implementation than adding a new "before" part.

Cheers,

Marten

Am 14.02.19 um 17:22 schrieb Robert Stepanek:
> rule to simplify specifying time-bounded recurrence rules. We'd be
> happy about your feedback.
>
> Currently, a JSCalendar recurrenceRule
> <https://tools.ietf.org/html/draft-ietf-calext-jscalendar-11#section-4.3.1> type
> is almost completely compatible with an iCalendar RRULE. The only
> difference is that the until property of a recurrenceRule is defined
> as a local time, whereas in iCalendar it must be a UTC time if DTSTART
> is a UTC time or a local time with time zone reference.
>
> recurrences, instead of "until". This "before" property would
> time-bound the recurrence set exclusively, whereas the UNTIL
> definition in iCalendar is inclusive. The rationale is that an
> exclusive "before" would allow to use the same value as boundary,
> regardless if the event is an all-day event. In contrast, using the
> current inclusive "until" requires two different values, depending on
> if the event is all-day or not.
>
> requires the until value to be "2019-02-14T00:00:00". However, if
> all-day is false, this would need to be "2019-02-14T23:59:59" to allow
> for all inclusive occurrences on that day. An exclusive "before" could
> in both cases be "2019-02-15T00:00:00".
>
> iCalendar, and we are wary of the risks involved. Yet, it clearly
> would make things simpler. What's your take on this?
>
> Cheers,
> Robert
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: [email-masked]

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743

---

From: "Neil Jenkins" <[email-masked]>
Date: Thu, 14 Feb 2019 19:08:18 -0500

On Fri, 15 Feb 2019, at 04:12, Marten Gajda wrote:
> I've never understood why iCalendar specified until to be inclusive in the first place. However, I also don't see much of a problem either.

Yes. My view is BEFORE is better than UNTIL, but possibly not enough better to justify deviating from iCalendar here (even if the two are trivially mapped between).

> If this is really a concern for some of us, there might be another solution to this approach: Just allow until to have a non-zero time component, even if all-day is true. This way "until=2019-02-14T23:59:59" could be used for all-day and non-all-day events.

> Conversion from iCalendar is trivial too: just append "T23:59:59" to the until date.

I'd be perfectly happy with this (indeed, this is what my implementation initially presumed).

Neil.

---

From: "Robert Stepanek" <[email-masked]>
Date: Fri, 15 Feb 2019 03:30:04 -0500

> I'd be perfectly happy with this (indeed, this is what my implementation initially presumed).

Sounds good to me. Let's do this.