Subject: Re: Can we fix BYSETPOS?

From: [email-masked]
Date: Mon, 11 Jun 2001 11:22:34 -0400

[email-masked] wrote on 06/08/2001 01:12:27 PM:
> See, this is what I mean about BYSETPOS being confusing.

Yep, the text about "set of events specified by the rule" (p. 44) is overly vague.  However it is possible to divine the intent 
from the examples (and hopefully we can get some common understanding 
about how to clarify this in the next update we make).  (Before folks 
start shooting me for this, Im just pseudo-Frank (TM) and psuedo-Derik 
(TM) in this and arguments about this concept should have happened when 
recurrence rules were first introduced; dont keep shooting the messenger 
w/the long memory and FT indexed archive!)

Each 'pass' thru the rule will generate a date or set of dates (and times) 
is the 'set' that is being referred to.  The original perception/intention 
of a rule was that it would become a 'template' for rolling out 'sets' of 
dates.  As such, it was desireable to be able to have a rule that could be 
'trimmed back' a bit or that could be made more accurate in what dates 
were generated by filtering the set and so BYSETPOS was created (much to 
the bane of my WG existance of late).

> So in my example above, the set is three quadrillion instances long, not
> sixty.

I can best explain how to this meaning by pointing to an example in 2445, 
the last one on p. 124:

   The 2nd to last weekday of the month:

     DTSTART;TZID=US-Eastern:19970929T090000
     RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-2

     ==> (1997 9:00 AM EDT)September 29
         (1997 9:00 AM EST)October 30;November 27;December 30
         (1998 9:00 AM EST)January 29;February 26;March 30
     ...

Ill try to take this step by step:

A: The FREQ is monthly (ie: Add 1 to the month value of the DTSTART for 
the next instance so it would be 29-Oct-1997, 29-Nov-1997, etc).  W/o any 
BYxxx modifiers the 'set' is effectively 1 recurrence per 'rollout' of the 
rule.

Next add in the BYxxx modifiers in order prescribed by the text at the 
bottom of p44. So we get...

B: The BYDAY modifier to make makes the 'set' effectively become "All 
Mondays, Tuesdays, Wednesdays, Thursdays and Fridays in the Month".  That 
makes the sets of dates become:
        1: [01-Sep-1997, 02-Sep-1997,..., 29-Sep-1997, 30-Sep-1997] in 1 
pass since we only evaluate the rule for the month of September given the 
DTSTART value (and the rules decodes as ALL weekdays in the month that 
contains DTSTART, since this is the 1st pass).

C: The BYSETPOS modfier is used to take the next to last value in the set 
("BYSETPOS=-2") so this set shrinks down to:
        1: [29-Sep-1997] which also happens to be the DTSTART value so 
this value is a duplicate value and is ignored (per the text in Section 4.8.5.1 Exception Date/Times, last line of the 1st paragraph of the Description.)

There are no other modifiers to apply so the 1st pass thru evaluating this 
rule yields a value of 29-Sep-1997 @ 9:00 AM EDT

A2: The next pass thru the rule starts by moving the evaulation point from 
the DTSTART by the FREQ and INTERVAL amount and become 29-Oct-1997. 

B2: Applying the BYDAY modifier again yields the set of dates of:
            2: [01-Oct-1997, 02-Oct-1997, 03-Oct-1997, 06-Oct-1997,..., 
30-Oct-1997, 31-Oct-1997]

C2: Applying the BYSETPOS again yields a final output of:
            2: [30-Oct-1997]

Again, there are no further modifiers to apply so the value from this pass 
is 30-Oct-1997 @ 9:00 AM EDT.

Does this help clarify things a bit??

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: Jonathan Lennox <[email-masked]>
Date: Mon, 11 Jun 2001 17:06:19 -0400 (EDT)

On Monday, June 11 2001, "[email-masked]" wrote to "Jonathan Lennox, Eric Busboom, [email-masked]" saying:

> about how to clarify this in the next update we make). 

[Description elided]

Actually, the reason I was confused is that the definition of the set
*isn't* clear from the examples, because the examples only show the use of
BYSETPOS with expanding BY* rules.  The confusion comes from the use of
BYSETPOS with contracting BY* rules, which no examples show.  (I suppose the
use of INTERVAL with BYSETPOS isn't technically ambiguous, but *I* certainly
mis-interpreted it.  No examples show this either.)

Consider, e.g.:

      DTSTART;TZID=US-Eastern:19970929T090000
      RRULE:FREQ=WEEKLY;BYMONTH=4,6;BYDAY=TU,TH;BYSETPOS=-1

Does this mean "The last Tuesday or Thursday of the week, every April and
June"?  Or "The last Tuesday or Thursday of April, and the last Tuesday or
Thursday of June, every year"?  Or "The last Tuesday or Thursday of (April
or June), every year"?

The conclusion we came to on the list, which got folded into Eric Busboom's
latest draft, is:
       BYSETPOS operates on a set of events in one interval of the
       recurrence rule. For a WEEKLY rule, the interval is one week, for a
       MONTHLY rule, one month, and for a YEARLY rule, one year.

I like this interpretation -- it's clean, simple, easy to explain, and easy
to compute.  If we re-allow the use of BYSETPOS with sub-day recurrences, as
you wanted (hopefully, with conditional restrictions forbidding it, using
the language that I had in my previous mail), this would apply to MINUTELY,
HOURLY, and DAILY rules as well, but the first sentence would still apply.
(BYSETPOS with a SECONDLY rule would never make sense.)

I'd extend this further, by changing the current sentence in RFC 2445
    It [BYSETPOS] MUST only be used in conjunction with another BYxxx rule
    part.
to
    It MUST only be used in conjunction with other BYxxx rule parts.  At
    least one of these BYxxx rule parts must be an "expanding" rule part,
    that is, a BYxxx rule part representing an interval of time smaller than
    FREQ.

Do you object to this?

-- 
Jonathan Lennox
[email-masked]