Subject: Seeking RRULE evaluation guidance

From: [email-masked]
Date: Fri, 30 Jun 2000 11:13:06 -0400

Warning: This is a rather long posting in an effort to be as clear as I can on my 
quandry!!

  Ok, after trying to figure out how some seemingly simple RRULE cases 
should be handled Ive come to the opinion that the RFC is not clear enough 
on the topic of evaluation for some cases.  The RFC has some good examples 
(thanks again Derik & Frank) but it is unclear how a recurrence rule 
should be evaluated when the FREQUENCY value is less than a BY* value, the 
INTERVAL is > 1 and the BY* is _NOT_ contiguous.

  For example with the following contiguous BYMONTH, just what are the 
rolled out values for the following:

DTSTART;TZID=US-Eastern:20000628T09000
DTEND;TZID=US-Eastern:20000628T093000
RRULE:FREQ=DAILY;COUNT=5;INTERVAL=4;BYMONTH=6,7

Should it be:

2000 9:00 AM EDT June 28;
                 July 2, 6, 10, 14, 18

or should it be:

2000 9:00 AM EDT June 28;
                 July 1, 4, 8, 12, 16

I suspect everyone will say the former case is correct.  (Anyone vote for 
the latter??)

  What if the BYMONTH were not contiguous:

DTSTART;TZID=US-Eastern:20000628T09000
DTEND;TZID=US-Eastern:20000628T093000
RRULE:FREQ=DAILY;COUNT=5;INTERVAL=4;BYMONTH=6,8

Should it be:

2000 9:00 AM EDT June 28;
                 August 3, 7, 11, 15, 19

or should it be:

2000 9:00 AM EDT June 28;
                 August 1, 4, 8, 12, 16 (or perhaps 4, 8, 12, 16, 20?)

There are 31 days in July and Ive heard 2 different ways to evaluate this 
recurrence "over" the intervening monthy of July.  One suggestion was to 
evaluate the rule thru July but rule out any value as 'out of bounds'. 
This leads to the former set of values.  The other suggestion was to 
evalueate the rule on a value by value basis thus evaluating August from 
the start (1-Aug-2000)

I can see both philosphies but Im not sure what the 'proper' one is.  I 
know others out there have done some recurrence engine work (Eric, 
Microsoft, iPlanet/Netscape??) so Im looking for some agreement as to the 
proper behaviour.  Id like to get concensus so we dont have interop 
issues!!

The case that started this off was simple enough so Ill add it here in 
case there is some interest: I need to take my medicine every 8 hours, 
every other day for 6 dosages.  If I specify:

DTSTART;TZID=US-Eastern:20000626T10000
DTEND;TZID=US-Eastern:20000626T100500
RRULE:FREQ=HOURLY;COUNT=6;INTERVAL=8;BYDAY=MO,WE,FR

then just what at the times I should be taking the medicine:

June 26 2000; 10:00 AM, 6:00 PM;
June 28 2000; 02:00 AM, 10:00 AM, 6:00 PM;
June 30 2000; 02:00 AM, 10:00 AM

or would it be:

June 26 2000; 10:00 AM, 6:00 PM;
June 28 2000; 12:00 AM, 8:00 AM, 4:00 PM;
June 30 2000; 12:00 AM, 8:00 AM

(or something entirely different??!)  The former case is derived from 
rolling out the values 'thru' the intervening days and just ignoring them. 
 The latter case is derived from rolling out the rule on a day by day 
basis (ie: Start @ DTSTARTs time on WE and evaluate all of WE, Start @ 
DTSTARTs time on FR and evaluate all of FR, etc).  The case gets messier 
if you use an INTERVAL that is not an even divisor of the BY* component 
(ie: 8 hours = 1/3 of a day).  Retry the example using an INTERVAL=5 or 
9...

This initial case (that I wrote last) is something most folks do routinely 
but in a slightly different way than how programs may think.  When I have 
to, say, take medicine on a (semi-)regular timetable, I base it on the 
same times each day rather than on any 'roll over' from the previous day. 
As I try to model my own needs using RRULEs Im starting to notice that 
some of the depth we thought we had is not quite there yet (albeit this is 
a very very deep topic!).

Ok, time to wake up and provide some useful responses...  Poke, poke, 
poke.  Nudge, nudge!

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Jon Wilson <[email-masked]>
Date: Fri, 30 Jun 2000 18:36:34 +0100 (BST)

On Fri, 30 Jun 2000 [email-masked] wrote:
> When I have to, say, take medicine on a (semi-)regular timetable, I
> base it on the same times each day rather than on any 'roll over' from
> the previous day.  

This interpretation of the rule conforms to the principle of least
surprise. 

However, consider the following situation. Imagine there is a job that
must be carried out every 4th day this year by a number of co-workers. We
agree that Jon shall carry out the task in month 1, Kevin shall do it
month 2, Laura in month 3, Jon again in month 4, and so on. This clearly
requires the other interpretation, with 'roll overs' for months where the
task is not scheduled and scheduling for an individual resuming with the
right interval from the previous enaction of the task by someone else.

(metric time anyone ... !)

--
Jon Wilson                                          [email-masked]
Dept. of Mathematical Sciences          http://www.bath.ac.uk/~mapjpw
University of Bath, UK                            Tel. (07776) 137939
"Never put off till tomorrow what you can put off till the day after"

---

From: Ross Finlayson <[email-masked]>
Date: Fri, 30 Jun 2000 13:35:06 -0700

(various examples deleted)

>The former case is derived from rolling out the values 'thru' the 
>intervening days and just ignoring them.  The latter case is derived from 
>rolling out the rule on a day by day basis

FWIW, I take the former interpretation in each case.  (At least, that's the 
way *I've* implemented it.)  If you want the latter interpretation, you can 
still do this using a second BY* for the smaller unit.

(One thing I noted about your examples, though, is that the number of 
occurrences you listed in each case was one more than the number specified 
in your COUNT - so perhaps you (or I) are misinterpreting what COUNT means??)

In any case, this is yet another illustration of the fact that the 
specification and description of RRULE is confusing, to say the 
least.  This also illustrates the perils of specifying something as a 
standard before it had been adequately implemented.  The IETF traditionally 
standardizes based on "rough consensus and running code".  In the case of 
RRULE, it seems that the second part of this was glossed over, if not 
omitted entirely.

         Ross.