RE: BYDAY and YEARLY

[pregen@xxxxxxxxxxxxxxxxxx]

We are in dialog with the original authors - maybe we can try to get some sort of ruling on what they think this should be.  And if it's wrong, we need to get it fixed.  We need to make some adjustments to the RFC's anyway because of findings from interop testing.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652

"Dan Hickman" <dhickman@xxxxxxxxxxxxxxxxxx> Sent by: owner-ietf-calendar@xxxxxxxxxxxx 07/08/2003 20:37

To:        <Bruce_Kahn@xxxxxxxxxxxxxxxx>, "Jonathan Lennox" <lennox@xxxxxxxxxxxxxxx>         cc:        <ietf-calendar@xxxxxxx>         Subject:        RE: BYDAY and YEARLY

The one thing that is obvious given the repeated conversations  on this topic is that the specification of BYDAY on YEARLY is ambiguous in the  RFC. I see both sides asvalid  interpretations. I suppose the real question is what was the original intention  of the author(s)?

Given the following:
1.  umerous VTIMEZONE examples in the RFC use "RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10" to mean  "The last Sunday in October", making it a big statement to say that these  are not valid.
2.There are a number of  implementations that already work this way now.
3.Rules like "The 5th Monday of the year but  only in February" are probably not that useful.

it appears there is much less impact if we go ahead and consider  "FREQ=YEARLY;BYMONTH=2;BYDAY=5MO" to mean the "5th Monday in  February". I suggest we accept this  interpretation.

Too bad I picked the wrong  interpretation to implement :-|

Regards,
Dan Hickman
Rockin' Software
dhickman@xxxxxxxxxxxxxxxxxx
http://www.rockinsoftware.com
-----Original Message-----
From:  owner-ietf-calendar@xxxxxxxxxxxx  [mailto:owner-ietf-calendar@xxxxxxxxxxxx]On Behalf Of  Bruce_Kahn@xxxxxxxxxxxxxxxx
Sent: Tuesday, July 08, 2003 2:07  PM
To: Jonathan Lennox
Cc:  ietf-calendar@xxxxxxx
Subject: Re: BYDAY and  YEARLY



Jonathan wrote on 07/08/2003  11:35:11 AM:
> I agree with this so far, but in your next step  (concluding that this means
> "the last Sunday in October") you make an  unwarranted leap.  The definition
> of the integer parts of BYDAY  says, as you quoted previously:
> 
> >    Each BYDAY  value can also be preceded by a positive (+n) or negative
> >     (-n) integer. If present, this indicates the nth occurrence of  the
> >    specific day within the MONTHLY or YEARLY RRULE.  
> 
> Thus, since this is a YEARLY RRULE, the phrase "Last Sunday"  means "Last
> Sunday of the Year", not "Last Sunday of the Month."   The presence of a
> BYMONTH rule doesn't affect this; by the spec,  the integer part of BYDAY
> depends *only* on the  FREQ.

The assumption about  BYDAY would be accurate without other BYxxx modifiers present.  When I  read: 

   If multiple BYxxx rule  parts are specified, then after evaluating the
  specified FREQ and  INTERVAL rule parts, the BYxxx rule parts are
  applied to the current  set of evaluated occurrences in the following
  order:  

I take the phrase "applied to the current  set of evaluated occurrences" to be that BYDAY works on the modified  occurrences generated by applying the BYMONTH first.  This BYxxx modifier  scopes the instance set to the month of October rather than the entire year.    

If BYMONTH were multivalued  (ie: BYMONTH=10,11,12) then the occurrences would be scoped to the months of  October thru December.  If no other BYxxx rule parts were there then Id  say that the rule would evaluate to "The last Sunday in December" but because  other BYxxx modfiiers were involved this is not true. 

On the top of page 45 in 2445 there is an example of  this that is pretty similar to Dans rule: 

   Here is an example of evaluating multiple BYxxx rule  parts.

    DTSTART;TZID=US-Eastern:19970105T083000
     RRULE:FREQ=YEARLY;INTERVAL=2;BYMONTH=1;BYDAY=SU;BYHOUR=8,9;
      BYMINUTE=30

  First, the "INTERVAL=2" would be  applied to "FREQ=YEARLY" to arrive
  at "every other year". Then,  "BYMONTH=1" would be applied to arrive
  at "every January, every  other year". Then, "BYDAY=SU" would be
  applied to arrive at "every  Sunday in January, every other year".
... 

This evaluates just like I did for the  BYDAY=-1SU;BYMONTH=10.  It follows the same logic I used (or I should say  that my logic followed it w/o actually seeing this @ first) by applying the  cited bits of 2445. 

>                                                                But this just
> means that the quoted  rule is vacuous, and its recurrence defines the empty
> set, except for  its DTSTART.   

I do not  think so given that the evaluation of the rule matches the way that the  multiple BYxxx parts are described to modify each other (and are not applyed  in parallel) and that the example in 2445 seems to confirm this.  

Bruce 
===========================================================================
Bruce  Kahn                                 INet:  Bruce_Kahn@xxxxxxxxxxxxxxxx
Messaging & Collaboration                  Phone: 978.399.6496
IBM Software  Group                          FAX: and nothing but the FAX...
Standard disclaimers apply,  even where prohibited by law...