Re: Questions regarding recurrence rules

This is a cryptographically signed message in MIME format.

--------------ms010407020705020400090201
Content-Type: multipart/mixed;
 boundary="------------010108020106000704040300"

This is a multi-part message in MIME format.
--------------010108020106000704040300
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


This is more documentation supporting my assertion that recurrence
rules are not as portable as many claim.

I would suggest using RDATE's and no RRULE or EXRULE. They are
easy to unwind, only after clearly defined and consistently used.

Reinhold Kainhofer wrote:
> 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=YEARLY;BYDAY=3SU
>>>Okay, that's the third sunday of the year. But what exactly is
>>>  RRULE:FREQ=YEARLY;BYDAY=5SU;BYMONTH=2
>>>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. 
> 
> 
> At first I thought so, too. But then, there are two reasons which seem to 
> contradict this:
> 
> 1) The RFC speaks of "within the MONTLY or YEARLY RRULE" (notice that they 
> don't say "within the frequency", like they do four lines below). So I 
> wondered if this might be the only place where it's relevant in which order 
> the BY* parts are evaluated.
> 
> 2) All VTIMEZONEs (at least those used by Exchange, Apple's iCal, and by 
> libical and so by evolution, korganizer etc.) use 
> RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
> 
> 
> 
>>RFC2445bis should add an example for this since its an area of confusion.
> 
> 
> Definitely.
> 
> 
>>>from rfc 2445. What is
>>>  RRULE:FREQ=YEARLY;BYDAY=5SU;BYMONTH=2,7
>>>Is this the fifth sunday of the year, if it's in either February or July?
>>>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 the 
> 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=MONTHLY;BYYEARDAY=57,64;BYDAY=-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", 
> you'll get:
> In each month, that days that are days 57 or 64 of the year. Within this rrule 
> (=within these days that match the rule so far), the last monday would be Feb 
> 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 (=#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=whatever:20050530T120000
>>>RRULE:FREQ=WEEKLY;COUNT=3;BYMONTH=6
>>
>>I'm sorry, I can't find where it says it right now to quote, but I have the
>>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 
> 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=US-Eastern:19970902T090000
>      RRULE:FREQ=WEEKLY;INTERVAL=2;UNTIL=19971224T000000Z;WKST=SU;
>       BYDAY=MO,WE,FR
>      ==> (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 the
>>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 kept.
> 
> 
> Yeah, the "can" is the issue. If I have a daily event that starts on a monday, 
> and add an exrule, which excludes all events on thursdays and fridays (here 
> the exrule uses the DTSTART, but it doesn't match the BY* parts). So, does 
> the DTSTART always match the EXRULE by definition (i.e. is the first monday 
> excluded, and all thursdays and fridays afterward), or does the first monday 
> 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 
> case where it would really make a different (if I understand RECURRENCE-ID 
> correctly, I don't see where this should matter, although RFC 2445 says it 
> does).
> 
> Cheers,
> Reinhold

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards


--------------010108020106000704040300
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consuiting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email protected]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email protected]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard


--------------010108020106000704040300--

--------------ms010407020705020400090201
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDUwNjAyMTkxNTI3WjAjBgkqhkiG9w0BCQQxFgQUhq3uxZTB6/FOUKYesi2Z
mqc/EjQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAsJyg6mNviZrVDuwETq/Raj3eUcuHpmnLfepDEAdCOo/qqslQC3RVhgnHVzJguSW/
/B0Z4on8esm33EPT/Y8ZU0hmCdJ1TdpVo/PXp3LnMqT+aIXfDGOsW6nn4RFwlRyeV6gnlAkL
cbzRVh3JpZasWNsBMtqR7YZPFYOLWpBmYtQhiAkZdjl/npQ6D62+CUhCGDWkpgyOV/k6F24F
5HmpWGo0JN2HwbeGV6z9uoTImax3jAEhRq86as2FPK6f6hTHubi3zYT2ha1G/NCZznqUBKOP
DtzxcuAIy7BLyD2o1UZoVSVObRxL2GA6SaBw3ezFSKKrFB8l3yk9aGqshJrrPAAAAAAAAA==
--------------ms010407020705020400090201--