Can anyone on the list help Bruce come up with a good example so we can get this BYSETPOS item resolved. It sounds like we are very close. However, I know there must be someone else out there besides Eric, Jonathan and Bruce who have an idea of an example.
Jonathan Lennox <lennox@xxxxxxxxxxxxxxx> Sent by: owner-ietf-calendar@xxxxxxxxxxxx
06/20/01 02:02 PM
To: Bruce_Kahn@xxxxxxxx
cc: Eric Busboom <eric@xxxxxxxxxxxxxxxxxx>, ietf-calendar@xxxxxxx
Subject: Re: Can we fix BYSETPOS?
On Wednesday, June 20 2001, "Bruce_Kahn@xxxxxxxx" wrote to "Jonathan Lennox, Eric Busboom, ietf-calendar@xxxxxxx" saying:
> >Why is the "set," for this rule, "all the events within a year" (or is it
> >"within a month"), rather than, say, "within a week" (FREQ) or "within
> >twenty-eight years" (least-common-multiple of BYMONTH and WEEKLY)?
>
> If you follow the decoding guidelines in Section 4.3.10 (p. 44 generally)
> then you decode the RRULE in the following way:
>
> 1: There is an implicit "INTERVAL=1" defined so this rule starts as "Every
> week" (or "Every week in the year forever" if you want a more verbose
> description")
> 2: "BYMONTH=4" refines it down to "Every week in April (forever)"
> 3: "BYSETPOS=1" refines it to "The first instance of the set of
> dates("Every week in April (forever)")"
Step 3 is the step I don't get, and it's where the definition of "set" is
crucial.
Clearly, "the set of dates consisting of the first instance of the set of
dates 'Every week in April, forever'" has exactly one member - one day in
April.
Similarly, "the set of dates consisting of the last instance of the set of
dates 'Every week in April, forever'" is ill-defined, as there is no such
last instance -- the set continues (as it says) forever.
So you're implicitly assuming some other algorithm for determining the
meaning of BYSETPOS, presumably derived from whatever algorithm you're using
to enumerate infinite sets.
If I decided to use an algorithm of "expand the set so that all events are a
constant-time offset from n * constant-period + DTSTART", my sets for the
above rule would be twenty-eight years in length (ignoring the Gregorian
correction and any year-dependent changes in time zone rules).
If I decided to use an algorithm of "for any given instance of n * FREQ +
DTSTART, check to make sure it complies with all the contracting rules and
INTERVAL, then apply the expanding rules", my set would be one week in
length (and would have only a single member).
Other than for BYSETPOS, both of these are reasonable implementation
strategies for recurrence rules, I think. I have to admit, though, I don't
see any implementation strategy for which "one year" is a natural resulting
set for this rule.
The standardized meaning Eric and I came up with was that the enclosing set
was the unit of time indicated by FREQ. This is a natural fit with the
second algorithm I said above, and is easy to explain and to understand.
However, this clearly isn't what you're doing. So I don't understand what
you *are* doing.
Can you explain it? I.e., do you agree with the following general
statements, and can you answer the question, in the model of recurrence rules
you're using?
Given a recurrence rule with a BYSETPOS rule, we have a period of
time P (possibly with an irregular length, such as a month) such that
BYSETPOS=1 indicates the first event following n * P + DTSTART for
integer n >= 0, and BYSETPOS=-1 indicates the last event preceding n *
P + DTSTART for integer n >= 1.
P is independent of INTERVAL, COUNT, UNTIL, and expanding BY* rules.
It depends only on FREQ and contracting BY* rules.
Given a recurrence rule with a specified FREQ and some number of
specified contracting BY* rules, how can you determine P?