RRULE using BYWEEKNO not working as I expected

[Mark McLaren]

I'm trying to convert an iCalendar feed from using RDATE to using RRULE because I have my suspicions that Mac OS X Calendar (iCal) does not support RDATE.

I thought it would be useful to use the google-rfc-2445 tool to check my logic.

An example list of dates is (using JodaTime's LocalDate and getWeekOfWeekyear()):

2013-01-28 5
2013-02-04 6
2013-02-11 7
2013-02-18 8
2013-02-25 9
2013-03-04 10
2013-03-11 11
2013-03-18 12
2013-04-22 17
2013-04-29 18
2013-05-06 19
2013-05-13 20

With a start date of "2013-01-28" by my reckoning the RRULE for these dates would be:

RRULE:FREQ=WEEKLY;BYWEEKNO=6,7,8,9,10,11,12,17,18,19,20;BYDAY=MO;COUNT=12

If I parse this rule using the google-rfc-2445 tool (and print out the getWeekOfWeekyear()), I get:

2013-01-28 5
2013-02-04 6
2013-02-11 7
2013-02-18 8
2013-02-25 9
2013-03-04 10
2013-03-11 11
2013-03-18 12
2013-03-25 13
2013-04-01 14
2013-04-08 15
2013-04-15 16

Is my RRULE logic wrong somewhere or is there a bug with the tool?

Thanks,

Mark

[Mike Samuel]

2012/10/16 Mark McLaren <mark.m...@gmail.com>:

> I'm trying to convert an iCalendar feed from using RDATE to using RRULE
> because I have my suspicions that Mac OS X Calendar (iCal) does not support
> RDATE.
>
> I thought it would be useful to use the google-rfc-2445 tool to check my
> logic.
>
> An example list of dates is (using JodaTime's LocalDate and
> getWeekOfWeekyear()):
>
> 2013-01-28 5
> 2013-02-04 6
> 2013-02-11 7
> 2013-02-18 8
> 2013-02-25 9
> 2013-03-04 10
> 2013-03-11 11
> 2013-03-18 12
> 2013-04-22 17
> 2013-04-29 18
> 2013-05-06 19
> 2013-05-13 20
>
> With a start date of "2013-01-28" by my reckoning the RRULE for these dates
> would be:
>
> RRULE:FREQ=WEEKLY;BYWEEKNO=6,7,8,9,10,11,12,17,18,19,20;BYDAY=MO;COUNT=12

TLDR; It's a reasonable rule, but the RFC doesn't require
implementations to handle it, and RFC 5545 explicitly disallows it. A
simple variation should work:
RRULE:FREQ=YEARLY;BYWEEKNO=6,7,8,9,10,11,12,17,18,19,20;COUNT=12 but I
haven't tested it.

-----

I'm not good at doing week number arithmetic in my head so I can't be
sure there's no off-by-1 error. The BYDAY=MO part is redundant with
your start date but harmless.

Whether it is strictly a bug depends on how you parse spec language

"""
A week is defined as a
seven day period, starting on the day of the week defined to be the
week start (see WKST). Week number one of the calendar year is the
first week which contains at least four (4) days in that calendar
year. This rule part is only valid for YEARLY rules.
"""

That last sentence suggests to me that BYWEEKNO is not valid except
when used in FREQ=YEARLY rules, but that only means that this library
doesn't have to honor it and that the usual test suites won't test for
it, not that this library shouldn't make a best effort to do what a
reasonable person (not a spec lawyer) would expect.

If you're in the mood for rank speculation, "the 3rd Monday"
(BYDAY=3MO) has a different meaning in month than in year and no
meaning in smaller periods, so perhaps the spec writers wanted to
avoid confusion by limiting BYWEEKNO to a single unambiguous meaning
that is orthogonal to numbered weekdays in a BYDAY rule.

RFC 5545 (which is the successor to RFC 2445) is less ambiguous and stricter

"""
The BYWEEKNO rule part specifies a COMMA-separated list of
ordinals specifying weeks of the year. Valid values are 1 to 53
or -53 to -1. This corresponds to weeks according to week
numbering as defined in [ISO.8601.2004]. A week is defined as a
seven day period, starting on the day of the week defined to be
the week start (see WKST). Week number one of the calendar year
is the first week that contains at least four (4) days in that
calendar year. This rule part MUST NOT be used when the FREQ rule
part is set to anything other than YEARLY.
"""

If you like, I can try and add support for WEEKLY rules with a
BYWEEKNO filter, but if you plan on using FREQ=WEEKLY with other RFC
2445 implementations you're likely out of luck, and you're on even
shakier ground if you need to work on a strict RFC 5545
implementation.