Re: Questions regarding recurrence rules

Reinhold Kainhofer <[email protected]> Thu, 2 Jun 2005 19:14:26 +0200
Newsgroups gmane.ietf.calendar
Organization FAM, Vienna University of Technology
Message-ID <[email protected]>
--nextPart1729649.f21ChoJ7gZ
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Thursday 02 June 2005 17:27, Sam Roberts wrote:
> Quoting [email protected], on Tue, May 31, 2005 at 03:59:12PM +0200:
> > Hi Guys,
> > 1) About the BYDAY rule part: Let's start with some examples
> >   RRULE:FREQ=3DYEARLY;BYDAY=3D3SU
> > Okay, that's the third sunday of the year. But what exactly is
> >   RRULE:FREQ=3DYEARLY;BYDAY=3D5SU;BYMONTH=3D2
> > Is this the fith sunday in the year, if it is also in february?
>
> Yes.
>
>    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. For example, within
>    a MONTHLY rule, +1MO (or simply 1MO) represents the first Monday
>    within the month, whereas -1MO represents the last Monday of the
>    month. If an integer modifier is not present, it means all days of
>    this type within the specified frequency. For example, within a
>    MONTHLY rule, MO represents all Mondays within the month.
>
> Whether it is an offset within a month or year depends on the FREQ, not on
> the presence of any other modifiers.=20

At first I thought so, too. But then, there are two reasons which seem to=20
contradict this:

1) The RFC speaks of "within the MONTLY or YEARLY RRULE" (notice that they=
=20
don't say "within the frequency", like they do four lines below). So I=20
wondered if this might be the only place where it's relevant in which order=
=20
the BY* parts are evaluated.

2) All VTIMEZONEs (at least those used by Exchange, Apple's iCal, and by=20
libical and so by evolution, korganizer etc.) use=20
RRULE:FREQ=3DYEARLY;BYMONTH=3D10;BYDAY=3D-1SU


> RFC2445bis should add an example for this since its an area of confusion.

Definitely.

> > from rfc 2445. What is
> >   RRULE:FREQ=3DYEARLY;BYDAY=3D5SU;BYMONTH=3D2,7
> > Is this the fifth sunday of the year, if it's in either February or Jul=
y?
> > Or is it the fifth sunday of febrary and july together (i.e. in feb if
> > the feb in a leap year has 5 sundays, or the first sunday of july in all
> > other years)?
>
> No way!

Actually, if the RFC really meant "within the RRULE", when that would be th=
e=20
correct interpretation. That's why I ask.

> > Also notice that rfc 2445 says "For example, within
> >    a MONTHLY rule, +1MO (or simply 1MO) represents the first Monday
> >    within the month, whereas -1MO represents the last Monday of the
> >    month. ". So what does
> >   RRULE:FREQ=3DMONTHLY;BYYEARDAY=3D57,64;BYDAY=3D-1MO
>
> Every month, the days that are the 57th&65th of the year (if in that
> month), and that are on the last monday of the month.

Depends. If you follow the RFC with the interpretation of "within the RRULE=
",=20
you'll get:
In each month, that days that are days 57 or 64 of the year. Within this rr=
ule=20
(=3Dwithin these days that match the rule so far), the last monday would be=
 Feb=20
27, 2007, and March 5, 2007....

> > mean? The last monday of each month if it's also day #57 or #64 of the
> > year (which the quote implies), or the last monday each month in the set
> > of all days #57 and #64 of the year. In particular, in 2007, would the
> > recurrence set be Feb 27 (=3D#57 of the year, and the last monday in
> > february) without any occurence in march (march 5 is day #64, but it's
> > not the last monday in the month, since rfc 2445 says -1MO means last
> > monday of the month)? Or would it be Feb 27 (day #57 of the year, and
> > last monday of all dates that match the BYYEARDAY in the february
> > interval) and March 4 ( day #64 of the year and last monday of all dates
> > in March that match the BYYEARDAY).




> > 2) In Section 4.3.10 RFC 2445 says "The COUNT rule part defines the
> > number of occurrences at which to range-bound the recurrence. The
> > "DTSTART" property value, if specified, counts as the first occurrence.=
".
> > So look at this rrule: DTSTART;TZID=3Dwhatever:20050530T120000
> > RRULE:FREQ=3DWEEKLY;COUNT=3D3;BYMONTH=3D6
>
> I'm sorry, I can't find where it says it right now to quote, but I have t=
he
> very distinct memory that RFC2445 says that the DTSTART property MUST
> specify a time that is valid according to the RRULE.

No, definitely not. E.g. even look at the examples given in RFC 2445. It=20
explicitly gives an example where the DTSTART does NOT match the RRULE:

   Every other week on Monday, Wednesday and Friday until December 24,
   1997, but starting on Tuesday, September 2, 1997:

     DTSTART;TZID=3DUS-Eastern:19970902T090000
     RRULE:FREQ=3DWEEKLY;INTERVAL=3D2;UNTIL=3D19971224T000000Z;WKST=3DSU;
      BYDAY=3DMO,WE,FR
     =3D=3D> (1997 9:00 AM EDT)September 2,3,5,15,17,19,29;October
     1,3,13,15,17
         (1997 9:00 AM EST)October 27,29,31;November 10,12,14,24,26,28;
                           December 8,10,12,22


> > 3) About the DTSTART and recurrence rules: Is the DTSTART always taken =
to
> > match the rule (even if it doesn't fulfil the BY* parts)? In particular
> > this is important for EXRULES: Is the DTSTART always the first occurence
> > of the EXRULE? If that's the case, the DTSTART will always be excluded =
as
> > soon as at least one EXRULE is present.
> > And since exceptions overrule inclusions, there's no way to have an
> > occurence on the DTSTART in that case... Is this really the intended
> > behaviour?
>
> I haven't implemented EXRULE (or ever seen one), but your argument that t=
he
> DTSTART will always be excluded looks right to me.
>
> That sounds like it would be a problem, but section 4.8.5.2 says this:
>
>    The "EXRULE" property can be used to exclude the value specified in
>                          ^^^
>    "DTSTART". However, in such cases the original "DTSTART" date MUST
>    still be maintained by the calendaring and scheduling system because
>    the original "DTSTART" value has inherent usage dependencies by other
>    properties such as the "RECURRENCE-ID".
>
> They say "can", maybe should say "would always" :-)
>
> It appears to me that DTSTART is made an exception, then, and must be kep=
t.

Yeah, the "can" is the issue. If I have a daily event that starts on a mond=
ay,=20
and add an exrule, which excludes all events on thursdays and fridays (here=
=20
the exrule uses the DTSTART, but it doesn't match the BY* parts). So, does=
=20
the DTSTART always match the EXRULE by definition (i.e. is the first monday=
=20
excluded, and all thursdays and fridays afterward), or does the first monda=
y=20
not match the EXRULE, and only all thursdays and fridays are excluded.


> So, don't make events whose alleged "start" is excluded from the set of
> events. This actually seems reasonable, why not just start the event when
> it actually starts?

Good question. I haven't thought of this too much, but I haven't yet seen a=
=20
case where it would really make a different (if I understand RECURRENCE-ID=
=20
correctly, I don't see where this should matter, although RFC 2445 says it=
=20
does).

Cheers,
Reinhold
=2D-=20
=2D-----------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email protected], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.a=
t/
 * K Desktop Environment, http://www.kde.org, KOrganizer / KPilot maintainer

--nextPart1729649.f21ChoJ7gZ
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBCnz53TqjEwhXvPN0RAhyUAJ9wSG4uAi91NmRI5ubB2dgLEWlF5gCgmdk5
9rsGDKULihBmsQvayG7KvQI=
=J/3b
-----END PGP SIGNATURE-----

--nextPart1729649.f21ChoJ7gZ--