Re: Changes to RECUR

[Jonathan Lennox <lennox@xxxxxxxxxxxxxxx>]

On Tuesday, March 27 2001, "Eric Busboom" wrote to "ietf-calendar@xxxxxxx" saying:

> Not all date BYxxx rule parts can appear simultaneously in a
> single recurrence rule. Date BYxxx rule part restrictions are:

What's the motivation for this?  Is the idea to forbid self-contradictory
rules, ones that never result in any recurrence at all?

It's not clear to me that that's really necessary.  A self-contradictory
rule isn't *ambiguous* -- it's clear that it means "no recurrence at all,
except for the DTSTART."   Mind you, a user interface probably wants to warn
the user if they've constructed a useless recurrence, but there's no
interoperability problem with them.

Also note that self-contradictory rules are still possible with your
restrictions, and I don't think they can in general be eliminated.  Consider
the obvious
RRULE:FREQ=YEARLY;BYMONTH=2;BYDAY=31
or the somewhat less obvious
DTSTART;TZID=America/New_York:20010329T0230
DURATION:T20M
RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU

In the interest of keeping the spec simple, I'd be inclined to say
"self-contradictory rules are allowed, and they mean no recurrence.  If the
total number of possible recurrences of an event is less than its COUNT
parameter, the COUNT parameter is ignored."

> [ The following is a change to section 4.3.10]
> 
> Change:
> 
>    The BYSETPOS rule part specifies a COMMA character (US-ASCII decimal
>    44) separated list of values which corresponds to the nth occurrence
>    within the set of events specified by the rule. Valid values are 1 to
>    366 or -366 to -1. It MUST only be used in conjunction with another
>    BYxxx rule part
> 
> To: 
> 
>    The BYSETPOS rule part specifies a COMMA character (US-ASCII decimal
>    44) separated list of values which corresponds to the nth occurrence
>    within the set of events specified by the rule. Valid values are 1 to
>    31622401 or -31622401 to -1. It MUST only be used in conjunction
>    with another BYxxx rule part
> 
> [31622401 is the number of seconds in a year plus a leap second, 366 *
> 24 * 60 * 60 + 1]

Is this really sufficient?  Are you sure you don't need the number of
seconds in a 28-year leap year cycle?  (Or worse, a 2800-year Gregorian leap
year cycle, but I'll ignore that for now.)

(This is the reason I dropped bysetpos from CPL...)

-- 
Jonathan Lennox
lennox@xxxxxxxxxxxxxxx