Skip to content

Recurring weekly configuration issue #73

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
LOKESH159 opened this issue Apr 6, 2020 · 5 comments
Closed

Recurring weekly configuration issue #73

LOKESH159 opened this issue Apr 6, 2020 · 5 comments

Comments

@LOKESH159
Copy link

LOKESH159 commented Apr 6, 2020

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]

@dmfs
Copy link
Owner

dmfs commented Apr 7, 2020

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.

@LOKESH159
Copy link
Author

LOKESH159 commented Apr 7, 2020

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;

@dmfs
Copy link
Owner

dmfs commented Apr 7, 2020

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.

dmfs added a commit that referenced this issue Apr 7, 2020
FastWeeklyIterator did not calculate dates correctly when the start date didn't match the rule. In practice the performance gain of this class should be neglible (if there is any at all). So this has been removed for being in the premature optimization category. Same goes for FastirthdayIterator.
@dmfs dmfs closed this as completed in 87c7752 Apr 7, 2020
@dmfs
Copy link
Owner

dmfs commented Apr 7, 2020

fixed in 0.11.5

@LOKESH159
Copy link
Author

LOKESH159 commented Apr 9, 2020

@dmfs When we can expect the jar in maven repository

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants