[caldeveloper-l] SKIP in RRULEs

Fri Oct 19 08:10:45 PDT 2018

Although it is not part of the RFCs, we spent considerable time in OASIS discussing the overlay or Availability and Unavailability. 

Availability is an under-appreciated Calendar object (https://tools.ietf.org/html/rfc7953) that makes heavy use of the RRules. 

In Simple terms, I might say “Call during Business hours” (What are they? Defined in Availability) but not on Holidays (what are they? An Unavailability object, laid atop the Business Hours). An Unvailability object is identical to an Availability object.

Smart Energy specifications make strong use of the Availability object, and the VAvailability Object (a bundle of 1 or more Availabilities) 

There is specific discussion on combining availabilities and computing Free-Busy in sections 4 and 5 of that document that seems to be the best discussion of how to unravel the questions in this thread.

There is a further discussion of the use of Vavailability in M2M service signaling for process control in the Energy Interoperation specification

http://docs.oasis-open.org/energyinterop/ei/v1.0/os/energyinterop-v1.0-os.html#_Toc388604087

tc

From: caldeveloper-l [mailto:caldeveloper-l-bounces at lists.calconnect.org] On Behalf Of Marten Gajda
Sent: Friday, October 19, 2018 4:39 AM
To: caldeveloper-l at lists.calconnect.org
Subject: Re: [caldeveloper-l] SKIP in RRULEs

Hi Neil,

IMO duplicate instances generated from an RRULE should be handled just like RRULE instances for which an RDATE exists. You merge them into one. RFC 5545 speaks of a "recurrence set" and "a set is a collection of distinct objects" (https://en.wikipedia.org/wiki/Set_(mathematics) ). So by definition the recurrence set can not contain two equal instances. This should answer 1 and 2.

Regarding 3, see the table on page 7 (https://tools.ietf.org/html/rfc7529#page-7)

   o  BYMONTH
   o  SKIP (for invalid month only)
   o  BYWEEKNO
   o  BYYEARDAY
   o  BYMONTHDAY
   o  SKIP (for invalid day)
   o  BYDAY
   o  BYHOUR
   o  BYMINUTE
   o  BYSECOND
   o  BYSETPOS
   o  COUNT
   o  UNTIL

It says that SKIP is applied before BYSETPOS. So In your example 2001-02-30 and 2001-02-31 would both wrap around to 2001-03-01 which becomes the 2nd instance of this particular set (even though it's in the next month), and also happens to be the first instance of the "March Set". So in this case 3 instances are merged into one.

That's my interpretation and how I intended to implemented it. However, I've just noticed that we return 2001-03-01 twice, which is not correct. I'll fix that.

Cheers,

Marten

Am 19.10.18 um 06:23 schrieb Neil Jenkins:

Hi everyone,

I'm trying to extend the JSCalendar recurrence rule expansion algorithm <https://tools.ietf.org/html/draft-ietf-calext-jscalendar-08#section-4.3.1>  to accommodate RFC7529 <https://tools.ietf.org/html/rfc7529#section-4.1>  and support RSCALE and SKIP. The former is easy, the latter seems to be a real pain. One big problem I'm running into is that the RFC seems to be quite under-specified when it comes to any kind of edge cases. So, can anyone help answer a few questions (presume DTSTART=20010201 for all of these):

1.	What happens if I generate duplicates due to SKIP; should they be removed, or considered separate occurrences? e.g. RSCALE=GREGORIAN;FREQ=YEARLY;BYMONTH=2,3;BYMONTHDAY=1,31;SKIP=FORWARD. I presume that should not generate two instances of 2001-03-01 despite this being the result of BYMONTH=2;BYMONTHDAY=31;SKIP=FORWARD as well as BYMONTH=3;BYMONTHDAY=1.
2.	What about if the duplicates occur in different periods, e.g. RSCALE=GREGORIAN;FREQ=MONTHLY;BYMONTHDAY=1,31;SKIP=FORWARD – should they still be removed?
3.	How does this interact with BYSETPOS? Are the duplicates removed before or after applying this? For example, RSCALE=GREGORIAN;FREQ=MONTHLY;BYMONTHDAY=1,30,31;BYSETPOS=1,2;SKIP=FORWARD – this might evaluate to 2001-02-01, 2001-02-30, 2001-02-31. We apply bySetPos and dedup (in either order) and get 2001-02-01, 2001-03-01. OK, now we continue to March. is 2001-03-01 considered for part of the BYSETPOS (so you get just 2001-03-30)? Or because it's already been generated from the Feb candidates due to the SKIP rule, is it eliminated before applying BYSETPOS (so you get 2001-03-30 and 2001-03-31)?

Looking forward to being enlightened on this,

Neil.

_______________________________________________
caldeveloper-l mailing list
caldeveloper-l at lists.calconnect.org <mailto:caldeveloper-l at lists.calconnect.org> 
http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten at dmfs.org <mailto:marten at dmfs.org> 

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.calconnect.org/pipermail/caldeveloper-l-calconnect.org/attachments/20181019/7ae94a42/attachment-0001.html>