Re: Can we fix BYSETPOS?

[Jonathan Lennox <lennox@xxxxxxxxxxxxxxx>]

On Wednesday, June 20 2001, "Bruce_Kahn@xxxxxxxx" wrote to "Jonathan Lennox, Eric Busboom, ietf-calendar@xxxxxxx" saying:

> Jonathan Lennox <lennox@xxxxxxxxxxxxxxx> wrote on 06/20/2001 02:02:49 PM:
> >[We're discussing
> >       RRULE:DTSTART;TZID=US-Eastern:20010406T090000
> >       RECUR:FREQ=WEEKLY;BYMONTH=4;BYSETPOS=1
> >]

> I sure wish that Frank or Vinod would pipe up for a change so that they 
> can help Jonathan understand this.  I don't seem to be doing a bang up job 
> of it.  I cannot give a purely mathematical defintion so Ive tried to 
> define by example (something I think I picked up from Frank along the 
> way).

> I think that before now there was some believe that the 'set' was all 
> possible instances ever (which makes BYSETPOS=-1 impossible for infinitely 
> repeating sets like our current example).

Yes, clearly that's wrong.  That was mostly just a complaint about the
terminology being unclear.  I didn't mean to harp on that point.

I think it's also clear that even for bounded sets, COUNT and UNTIL apply
*after* BYSETPOS.

> Ill try another description to see if I can clarify it while I poke the 
> others OOB to provide an answer that may help you further.  In Step #2 we 
> have a set or 'template' (new term to try and get around any mental 
> baggage) for the rule that contains "Every week in April (forever)".  That 
> is, it contains:
> 
> 1: The (effective) DTSTART date/time (call it DTS0).  In reality it is 20010406T090000.
> 2: DTS0 + "1 week" (DTS1).  In reality it is 20010413T090000.
> 3: DTS1 + "1 week" (DTS2).  In reality it is 20010420T090000.
> 4: DTS2 + "1 week" (DTS3).  In reality it is 20010427T090000.
> 
> There is no #5 since DTS3 + "1 week" would put it outside the BYMONTH 
> value for 2001 but it MAY exist eventually in some years. 
> 
> The template does NOT contain 20020405T090000, 20020412T090000, etc. since 
> that would be another Aprils worth of values and that would require 
> evaluating the subcomponents again (ie: another pass down the evaluation 
> order).  We do not do this since that is basically reevaluating the rule 
> at its next starting point using a the BYMONTH over again. 

So you're saying that the duration of the 'template' depends on the largest
BY* rule (or FREQ, if that's larger) mentioned in the rule.

I really don't like that -- I think the interpretation which I, Eric, and
Robert advocate is both much more useful and much easier to explain.

Here's why.  Consider the following three rules:

       RRULE:DTSTART;TZID=US-Eastern:20010401T090000
       RECUR:FREQ=WEEKLY;BYMONTH=4,6;BYDAY=FR;BYSETPOS=-1

       RRULE:DTSTART;TZID=US-Eastern:20010401T090000
       RECUR:FREQ=MONTHLY;BYMONTH=4,6;BYDAY=FR;BYSETPOS=-1

       RRULE:DTSTART;TZID=US-Eastern:20010401T090000
       RECUR:FREQ=YEARLY;BYMONTH=4,6;BYDAY=FR;BYSETPOS=-1

As far as I can generalize from your example, these three examples under
your interpretation would be *identical* -- the FREQ is completely
irrelevant.  They all generate "The last Friday of (April or June)".

Under my interpretation, these would be, respectively, "the last Friday of
the week, in April and June" (i.e. "Fridays in April and June"); "the last
Friday of April, and the last Friday of June"; and "the last Friday of
(April or June)" (i.e., given DTSTART, "The last Friday of June").

Regardless of what RFC 2445 seems to say (and I think it's apparent by now
that this is terribly unclear), do people agree that the above
interpretation is what RRULE *should* mean?

-- 
Jonathan Lennox
lennox@xxxxxxxxxxxxxxx