Recurring weekly configuration issue
Closed this issue · 5 comments
Hi, I create a recurring event based on the below configuration
Event start time : 2020-04-04T10:00:00Z
Event end time : 2020-04-04T11:00:00Z
Rule: "FREQ=WEEKLY;INTERVAL=2;WKST=SU;BYDAY=TU;UNTIL=20200430T170000Z"
TimeZone Id: "GMT"
The library is giving instance datetimes as [2020-04-07T10:00:00Z,2020-04-21T10:00:00Z].
Actually I am expecting the instance datetimes as [ 2020-04-14T10:00:00Z,2020-04-28T10:00:00Z].
Will the library will start based on the first occurrence of the events? Correct me If I am wrong. When I checked in google and office 365 calendar based on the above configuration it's creating the events based on I am expecting dates.
The one thing I noticed is the BYDAY size is 1. It's not giving the expected output.
PROGRAM
`String rule ="FREQ=WEEKLY;INTERVAL=2;WKST=SU;BYDAY=TU;UNTIL=20200430T235900Z";
RecurrenceRule recurrenceRule = new RecurrenceRule(rule, RecurrenceRule.RfcMode.RFC5545_STRICT);
RecurrenceRuleIterator recurrenceRuleIterator = recurrenceRule.iterator(1585994400000l,TimeZone.getTimeZone("GMT"));
while(recurrenceRuleIterator.hasNext()){
System.out.println(recurrenceRuleIterator.nextDateTime());
}`
OUTPUT
[20200407T100000,20200421T100000]
Expected Output
[20200414T100000,20200428T100000]
The problem is, that your start is not synchronized with the RRULE, i.e. 2020-04-04 is not a Tuesday.
As per RFC 5545 start dates should match the rule and the result is "undefined" otherwise, whatever that means.
Nonetheless, I agree this is unexpected behavior. I' pretty sure this regression was introduced when I removed unsynchronized start dates from being iterated. As a result they were no longer counted as first instance. I presume a similar issue applies to BYSETPOS now (when used with start dates not matching the rule).
I'll think of something to fix this.
File Name : FastWeeklyIterator.java
BYDAY size is 1. getInstance() in FastWeeklyIterator.java. It's calculating the wrong yearDay because I think you are not considering the interval.
yearDay += (weekday - currentWeekDay + 7) % 7;
Right, I came to the same conclusion. Yet another case of premature optimization. I'll remove the entire class. The added complexity is not worth it. The regular weekly iteration is probably just as fast and works as expected.
fixed in 0.11.5