[Ietf-calsify] BYDAY integers with other BY* rules (was: BYSETPOS and contracting BY* rules)

[Nigel Swinson]

> I've always agreed with your second interpretation of RFC 2445: the 
> numbers
> in the BYDAY rule refer to the period of time described by the FREQ. 
> "-1FR"
> means the last Friday of the month in a MONTHLY rule, and the last Friday 
> of
> the year in a YEARLY rule.

<snip>

> Unfortunately, this interpretation is directly contradicted by RFC 2445's
> VTIMEZONE example, which describes US-Eastern DST transitions as
>
>         RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
>
> I've always interpreted this VTIMEZONE example as a bug in the spec, but I
> see how it can make sense if BYDAY integers are interpreted as being like
> BYSETPOS.

Recommendations detailed in 
http://www.calconnect.org/publications/icalendarrecurrenceproblemsandrecommendationsv1.0.pdf 
in appendix A say that FREQ Yearly with BYDAY means read note 3.  Note 3 
says:

 Limit if BYYEARDAY or BYMONTHDAY is present,
 otherwise special expand for WEEKLY if BYWEEKNO present,
 otherwise special expand for MONTHLY if BYMONTH present,
 otherwise special expand for YEARLY.

 A BYDAY rule part cannot have a numeric value in a
 FREQ=YEARLY rule (i.e. 'MO', 'TU' etc is allowed, but
 '1MO', '2TU' is not allowed), if BYWEEKNO is specified.

 The numeric value in a BYDAY rule part in a FREQ=YEARLY
 rule with a BYMONTH present corresponds to an offset with
 the month.

 The numeric value in a BYDAY rule part in a FREQ=YEARLY
 rule without BYWEEKNO or BYMONTH

So BYMONTH present means special expand for MONTHLY, and special expand for 
MONTHLY means  "The numeric value in a BYDAY rule part in a FREQ=YEARLY rule 
with a BYMONTH present corresponds to an offset with the month".  Thus that 
makes the example not nice, but not buggy either?

Are we wanting to abandon those recommentations?  The very fact that BYDAY 
needed three special notes, the only special notes in the whole table make 
me wonder if somethings wrong :o/

Nigel