Re: Questions regarding recurrence rules

Reinhold Kainhofer <[email protected]> Fri, 3 Jun 2005 17:47:29 +0200
Newsgroups gmane.ietf.calendar
Organization FAM, Vienna University of Technology
Message-ID <[email protected]>
--nextPart1564412.N6PQJJTH6z
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello guys,
I did some more digging in various mailing list archives, re-read rfc 2445 =
a=20
few times and throught a little more on the issues.

On Tuesday 31 May 2005 15:59, Reinhold Kainhofer wrote:
> 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.".=20
[...]
> Now if the DTSTART is not specified the quote from above would imply that
> the start doesn't count as a recurrence, so looking at
> DTEND;TZID=3Dwhatever:20050530T150000
> DURATION:PT3H
> RRULE:FREQ=3DWEEKLY;COUNT=3D3;BYMONTH=3D6
> would give the following resulting recurrence dates?
>   1) 20050530 (DTSTART is always the first occurence, )
>   2) 20050630
>   3) 20060630
>   4) 20070630 (DTSTART doesn't count towards COUNT)


I thought about this issue some more, and I tend to think that the phrase "=
if=20
specified" in the RFC 2445 is actually meant to mean "if the DTSTART matche=
s=20
the recurrence rule" (not if the DTSTART is present in the VEVENT at all). =
In=20
particular this would mean that
  DTSTART;VALUE=3DDATE:20050603
  RRULE:FREQ=3DWEEKLY;BYDAY=3DMO,WE;COUNT=3D3
gives the recurrence set June 3 (DTSTART), June 6, 8, and 13 (the first thr=
ee=20
occurences defined by the RRULE).

Also, in the rule
  DTSTART;VALUE=3DDATE:20050603
  RRULE:FREQ=3DWEEKLY;BYDAY=3DWE,FR;COUNT=3D3
the recurrence set is generated by the DTSTART plus the first three occuren=
ces=20
of the RRULE (June 3, 8 and 10). As a result the recurrence set would only =
be=20
June 3, 8, and 10 (June 3 is duplicate from the DTSTART and the RRULE, but=
=20
rfc 2445 says that means it only appears once).


> 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 so=
on
> 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?

After re-reading the rfc several times, and reading a thread on the libical=
=20
mailing list from July 2002=20
(http://www.softwarestudio.org/mail-archives/libical/0680.html, see the=20
thread following this initial mail for the relvant comments), I don't think=
=20
that the DTSTART is meant to be automatically part of the recurrence set=20
generated by the RRULE (only if it matches the BY* parts). So, basically,=20
this means that=20
  DTSTART;VALUE=3DDATE:20050603
  RRULE:FREQ=3DDAILY
  EXRULE:FREQ=3DWEEKLY;BYDAY=3DMO,WE;COUNT=3D3
excludes only Mo June 6, We June 8, and Mo June 13 (the count applies only =
to=20
the nr of dates that actually match the rule, as explained above; and the=20
DTSTART is not automatically excluded by the EXRULE, since otherwise the=20
phrase "can be used to exclude ... DTSTART" doesn't make sense).

Can anyone confirm this?

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

--nextPart1564412.N6PQJJTH6z
Content-Type: application/pgp-signature

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

iD8DBQBCoHuRTqjEwhXvPN0RAv2DAJ9p5n0X5ZDy+mV3U1qspaMKPIyoagCdFJq7
StCQnq/BPc5QoSe46HCU5P0=
=u96d
-----END PGP SIGNATURE-----

--nextPart1564412.N6PQJJTH6z--