The following rule

FREQ=YEARLY;BYWEEKNO=1,3,4,5,8,9;BYYEARDAY=1,14,31,60

Returns only January 1st of certain years:

{"instances":["20240101","20290101","20350101","20410101","20460101","20520101","20570101","20630101","20690101","20740101","20800101","20850101","20910101","20970101"],"info":{"nanoseconds_per_instance":79882.07,"number_of_instances_in_result":14,"parser_mode":"RFC5545_LAX","iterator_nanos":1118349,"rule_parser_nanos":77362,"total_nanos":1195711,"lib-recur-version":"0.10.2","has_next":true,"is_infinite":true}}

but we would expect something like

2018-01-01, 2018-01-31, 2018-03-01, 2019-01-01, 2019-01-14, 2019-01-31, 2019-03-01, 2020-01-01, 2020-01-14, 2020-01-31
// Any day that is 1st, 14th, 31st or 60th of a year and also falls in week number 1, 3, 4, 5, 8, or 9.

Speaking about

Integer.parseInt allows signs in the value strings. These are, however, invalid in time stamps. Calendar.parse should throw an IllegalArgumentException.

[EDIT] Testcases:

    @Test(expected = IllegalArgumentException.class)
    public void testInvalidPlusSign()
    {
        new TestDate("+2011122T223344Z").setDate(201, Calendar.NOVEMBER, 22).testEvent();
    }


    @Test(expected = IllegalArgumentException.class)
    public void testInvalidMinusSign()
    {
        new TestDate("-2011122T223344Z").setDate(201, Calendar.NOVEMBER, 22).testEvent();

    }

Standard explicitly forbids this. The parser should throw an exception.

Test:

"FREQ=WEEKLY;BYDAY=MO;FREQ=DAILY"

These conditions are

• Integer must only be set when FREQ is YEARLY or MONTHLY

The BYDAY rule part MUST NOT be specified with a numeric value when the FREQ rule part is not set to MONTHLY or YEARLY.

• Integer must not be set when FREQ is YEARLY and BYWEEKNO is set

Furthermore, the BYDAY rule part MUST NOT be specified with a numeric value with the FREQ rule part set to YEARLY when the BYWEEKNO rule part is specified.

In RFC5545_Strict mode we have to throw an exception, in all other cases we just drop it.

Speaking about

In this example:

DTSTART;TZID=America/Chicago:20160120T060000
DTEND;TZID=America/Chicago:20160120T070000
RRULE:FREQ=WEEKLY;COUNT=10;BYDAY=WE

It seems like using the existing API, we can get a list of start DateTime(s) from RecurrenceRuleIterator.nextDateTime()

However, there is no obvious way to get the end DateTime for each instance. To do that, we would need to either calculate the duration between DTSTART and DTEND manually (is there support for creating a DURATIOn from two DateTime(s)?) or to create two RecurrenceRuleIterators using rRule.iterator(DTSTART) for the first one and rRule.iterator(DTEND) for the second one, then co-iterate them.

Is there a cleaner way to do this? would it be a good idea to return a structure with start,end from RecurrenceRuleIterator.getNextDateTime()

Probably related to #8 .

Test:

"FREQ=DAILY;UNTIL=20130101;COUNT=12"

In order to write better tests more easily, I want Hamcrest Matchers to validate the recurrence results.

The parser should rather throw an InvalidRecurrenceRuleException, shouldn't it?

Test

"FREQ=YEARLY;BYDAY=MO;INTERVAL=MO"

I discovered that when using two or more recurrence rules within a single RecurrenceSetIterator, calling next() on the iterator sometimes returns the next few date/times out of order.

A reproducible example is below, where we have two recurrence rules (every 5 hours and every day), both with a start time of 1/1/2019 at 12am. When fast-forwarding the iterator to 10pm, next() returns 1/2/2019 at 1am instead of 1/2/2019 at 12am. Calling next() again, however, returns 1/2/2019 at 12am, which is backwards in time from what it returned previously.

import org.junit.Test;

@Test
public void lib_recur_test() throws InvalidRecurrenceRuleException {

  // We are calculating for the next recurrence after 1/1/2019 at 10pm.
  ZoneId localTimeZone = ZoneId.of("UTC");
  final ZonedDateTime timeOfCalculation = ZonedDateTime.of(2019, 1, 1, 22, 0, 0, 0, localTimeZone);

  // Combine all Recurrence Rules into a RecurrenceSet
  RecurrenceSet ruleSet = new RecurrenceSet();
  ruleSet.addInstances(new RecurrenceRuleAdapter(new RecurrenceRule("FREQ=HOURLY;INTERVAL=5")));
  ruleSet.addInstances(new RecurrenceRuleAdapter(new RecurrenceRule("FREQ=DAILY;INTERVAL=1")));

  ZonedDateTime startDateTime = ZonedDateTime.of(2019, 1, 1, 0, 0, 0, 0, localTimeZone);
  long startTimeEpochMillis = startDateTime.toInstant().toEpochMilli();

  // Create an iterator using the RecurrenceSet
  RecurrenceSetIterator it = ruleSet.iterator(TimeZone.getTimeZone(localTimeZone), startTimeEpochMillis);

  // Fast forward to the time of calculation (1/1/2019 at 10pm).
  it.fastForward(timeOfCalculation.toInstant().toEpochMilli());

  if (it.hasNext()) {

    long nextRunTimeEpochMillis = it.next();

    // The next run time should be 1/2/2019 at 12am, due to the Daily recurrence rule defined above.
    ZonedDateTime expectedNextRunTime = ZonedDateTime.of(2019, 1, 2, 0, 0, 0, 0, localTimeZone);

    // However, the calculated next run time returns 1am.
    ZonedDateTime calculatedNextRunTime = ZonedDateTime.ofInstant(Instant.ofEpochMilli(nextRunTimeEpochMillis), localTimeZone);

    // Fails
    Assert.assertEquals(expectedNextRunTime, calculatedNextRunTime);
  }
}

In most parts of parser we throw an InvalidRecurrenceRuleException. In order to stay consistent we should also do so here.

Test: (BYMONHT is unkown)

"FREQ=YEARLY;BYMONHT=2"

Current exception:

java.lang.IllegalArgumentException: No enum constant org.dmfs.rfc5545.recur.RecurrenceRule.Part.BYMONHT

Standard prohibits this:

"[...] This rule part is only valid for YEARLY rules."

Test:

"FREQ=MONTHLY;BYWEEKNO=26"

TL;DR: Exception Dates added via RecurrenceSet.addExceptions(...) don't seem to actually prevent iteration to recurrences that would normally occur on added dates.

For example, assume I have a RecurrenceSet object named ruleSet. I first call ruleSet.addInstances(...) on my set object to add a simple Recurrence Rule such as FREQ=DAILY;COUNT=5. I then call something like ruleSet.addExceptions(new RecurrenceList("20190125", null)) to add a single Exception Date (January 25, 2019) to my ruleSet.

If I then use ruleSet.iterator(...) to get an iterator, starting on January 24, 2019 (at whatever time the Event starts at), and proceed to iterate over the recurrences it provides, I will still end up being handed a timestamp corresponding to January 25, 2019 (at whatever time the Event starts at) in the time zone I provided.

This seems to be broken functionality. Further, I looked through the tests for this library and couldn't find any that actually test ExDates. I'm wondering if I am using this feature of the library wrong, or if this is a bug?

I discovered that when using two or more recurrence rules within a single RecurrenceSetIterator, calling next() on the iterator sometimes returns the next few date/times out of order.

A reproducible example is below, where we have two recurrence rules (every 5 hours and every day), both with a start time of 1/1/2019 at 12am. When fast-forwarding the iterator to 10pm, next() returns 1/2/2019 at 1am instead of 1/2/2019 at 12am. Calling next() again, however, returns 1/2/2019 at 12am, which is backwards in time from what it returned previously.

` // We are calculating for the next recurrence after 1/1/2019 at 10pm.
ZoneId localTimeZone = ZoneId.of("UTC");
final ZonedDateTime timeOfCalculation = ZonedDateTime.of(2019, 1, 1, 22, 0, 0, 0, localTimeZone);

// Combine all Recurrence Rules into a RecurrenceSet
RecurrenceSet ruleSet = new RecurrenceSet();
ruleSet.addInstances(new RecurrenceRuleAdapter(new RecurrenceRule("FREQ=HOURLY;INTERVAL=5")));
ruleSet.addInstances(new RecurrenceRuleAdapter(new RecurrenceRule("FREQ=DAILY;INTERVAL=1")));

ZonedDateTime startDateTime = ZonedDateTime.of(2019, 1, 1, 0, 0, 0, 0, localTimeZone);
long startTimeEpochMillis = startDateTime.toInstant().toEpochMilli();

// Create an iterator using the RecurrenceSet
RecurrenceSetIterator it = ruleSet.iterator(TimeZone.getTimeZone(localTimeZone), startTimeEpochMillis);

// Fast forward to the time of calculation (1/1/2019 at 10pm).
it.fastForward(timeOfCalculation.toInstant().toEpochMilli());

if (it.hasNext()) {
  long nextRunTimeEpochMillis = it.next();

  // The next run time should be 1/2/2019 at 12am, due to the Daily recurrence rule defined above.
  ZonedDateTime expectedNextRunTime = ZonedDateTime.of(2019, 1, 2, 0, 0, 0, 0, localTimeZone);

  // However, the calculated next run time returns 1am. 
  ZonedDateTime calculatedNextRunTime = ZonedDateTime.ofInstant(Instant.ofEpochMilli(nextRunTimeEpochMillis), localTimeZone);

  // Fails
  Assert.assertEquals(expectedNextRunTime, calculatedNextRunTime);
}`

We expect the following code to generate the 2017-08-07:

RecurrenceRule rule = new RecurrenceRule("FREQ=WEEKLY;INTERVAL=1;BYDAY=MO");
DateTime ruleStartDate = new DateTime(2017, 1 - 1, 13, 0,0,0);
DateTime iteratorStartDate = new DateTime(2017, 8 - 1, 7, 0,0,0);
DateTime iterationEndDate = new DateTime(2017, 8 - 1, 8, 23, 59,59);
rule.setUntil(iterationEndDate);

RecurrenceRuleIterator it = rule.iterator(ruleStartDate);
it.fastForward(iteratorStartDate);

while (it.hasNext()) {
    DateTime nextInstance = it.nextDateTime();
    System.out.println(nextInstance);
}

But unfortunately it doesn't.

If we change iteratorStartDate to 2017-07-31 we get the expected list of
2017-07-31
2017-08-07

This seem to happen when the day of month is something less than 8 in every month in 2017. But this is only a guess. Do you have an idea what happens here?

RFC 7529 states:

Only a few types of recurrence patterns are likely to need the use of
"SKIP". The following is a list of some situations where it might be
needed:
…
7. A "BYYEARDAY" element in an "RRULE" has an absolute value greater
than the smallest number of days in any year in the specified
calendar system.

8. A "BYWEEKNO" element in an "RRULE" has an absolute value greater
   than the smallest number of weeks in any year in the specified
   calendar system.

These cases are not properly handled yet:

20150213T000000
FREQ=YEARLY;RSCALE=GREGORIAN;SKIP=BACKWARDS;BYYEARDAY=366
=> "20161231T000000","20201231T000000","20241231T000000","20281231T000000","20321231T000000","20361231T000000"

20150213T000000
FREQ=YEARLY;RSCALE=GREGORIAN;SKIP=BACKWARDS;BYWEEKNO=53
=> "20210101T000000","20260102T000000","20320102T000000","20370102T000000","20430102T000000"

In both cases the results should occur once per year

setByDayPart method is missing the else condition wrapper around the put call similar to its partner method setByPart

Hello,

Here's a rule that we are receiving from an another system/library:
WKST=MO;FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SU;INTERVAL=1;BYHOUR=21;BYMINUTE=0;DTSTART=20161022T210000Z;TIMEZONE=Europe/Helsinki

The written version would be something like this: "Repeat on Mo,Tu,We,Th,Fr,Su at 21:00 EEST (+0300), starting from 22 Oct 2016 21:00:00 UTC".

Lib-recur seems to get a bit confused with timezones when parsing this rule and it produces occurrences such as 20161023T210000 (Mon Oct 24 00:00:00 EEST 2016).

Here's an example (Scala) code which I use to initialize the recurrence rule.
val rr = new RecurrenceRule(rrule) val start = new DateTime(starting.getTimeInMillis) val rrIter = rr.iterator(start) if(rrIter.hasNext) rrIter.nextDateTime() ...

br,
Timo

(I'm not entirely sure that if the rule we get from the another lib is actually standards compliant)

In order to make the code simpler (and potentially faster), I want the ByDayFilter to by split into four classes.

In order to judge the effect of changes on performance, as a developer I want a way to benchmark the recurrence iteration.

Test (SO should be SU)

FREQ=YEARLY;BYDAY=-1SO

Hi, I have the following rule
String rrule="FREQ=DAILY;BYDAY=SA,SU;UNTIL=20171130T000000Z" and my start date is "20171101T000000Z"

Here start date is 1 November 2017 and end date is 30 November 2017 now the event will be occur only on saturday and sunday as per rrule mean (4,5,11,12,18,19,25,26Nov) but Problem is that event is also occuring for 1 November where day is Wednesday which should not be happen. Please tell me why I am getting 1 November event. Below is my code ,please check and provide the best solution for this

   DateTime firstInstance = DateTime.parse("20171101T000000Z");
   RecurrenceRule rRuleForSession = null;
                    try {
                        rRuleForSession = new RecurrenceRule(rrule);
                    } catch (InvalidRecurrenceRuleException e) {
                        e.printStackTrace();
                    }
    RecurrenceSet rset = new RecurrenceSet();
    rset.addInstances(new RecurrenceRuleAdapter(rRuleForSession));
   rset.addExceptions(new RecurrenceList("20171130T000000Z", firstInstance.getTimeZone()));

   RecurrenceSetIterator itrRecurrence = 
   rset.iterator(firstInstance.getTimeZone(),firstInstance.getTimestamp());
                    
             int maxInstance = 1;
                    while (itrRecurrence.hasNext() && --maxInstance >= 0) {
                        long nextInstance = itrRecurrence.next();
                        DateTime dateTime = new DateTime(TimeZone.getDefault(), nextInstance);
                        Toast.makeText(baseActivity,dateTime.toString(),Toast.LENGTH_SHORT).show();
                         }

In order to prepare the solution for #40 I want the expanders to be split into simpler ones.

BYWEEKNO expansion does't work correctly when expanding a day which technically belongs to the previous or next year.
Example

RRULE:FREQ=YEARLY;BYWEEKNO=1
DTSTART:20180101

expands to:

"20180101","20191231","20201230","20210104","20220103","20230102","20240101"

Note the instance 20191231 which should be 20181213 because the expansion inherits the day of week, which is Monday in this case. Monday of the first week of 2019 is actually December 12 2018 though.

TBD

Standard forbids this.

 "[...] It MUST only be used in conjunction with another
      BYxxx rule part. "

Test:

"FREQ=YEARLY;BYSETPOS=1"

Example:

"FREQ=YEARLY;BYMONTH=2;BYMONTH=3;BYMONTH=4"

We have several options here.

1. Throw an exception (probably nonsense since we're in Lax mode)
2. Either pick the first or the last one, ie. "BYMONTH=2" or "BYMONTH=4"
3. Merge them together into one list, ie. "BYMONTH=2,3,4"

For the instance expansion in the task provider we need a method to fast forward instances, i.e. skip all instances until a specific date.

The following method will provide that feature:

/**
 * Skip all instances till a specific date.
 * <p>
 * <strong>Note:</strong> After calling this method you should call {@link #hasNext()} before you continue because there might no more instances left if there is an UNTIL or COUNT part in the rule.
 * </p>
 * 
 * @param until
 *              The earliest date to be returned by {@link #next()}.
 */
public void skip(Calendar until)

When switching to DST ("Sommerzeit") in Europe/Berlin 2:30AM must not occur.

Test-rule:

FREQ=YEARLY;UNTIL=20200101T010101Z;BYMONTH=3;BYDAY=-1SU;BYHOUR=2;BYMINUTE=30

Test-case:

mTestRules.add(new TestRule("FREQ=YEARLY;UNTIL=20200101T010101Z;BYMONTH=3;BYDAY=-1SU;BYHOUR=2;BYMINUTE=30")
            .setStart("20120101T010101", "Europe/Berlin").setInstances(1));

Right now we get 9 instead of 1.

It seems that lib-recur is missing substring "RRULE:" before any recurrent rule as in rfc5545 doc

When iterating over a RecurrenceSet with an RRULE which contains a COUNT parameter and the start date doesn't match the pattern, RecurrenceSetIterator returns one element too much. This is a result of the previous change which remove any unsynced start instance from the RecurrenceRuleIterator results.

See https://github.com/dmfs/lib-recur/blob/master/src/org/dmfs/rfc5545/recur/Calendar.java#L237 .

If the recurrence set contains more than just one InstanceIterator the fast path when just one of them still has more elements is never entered.

When passing a valid ReccurenceRule, e.g.

"FREQ=WEEKLY;BYDAY=MO"

the parser throws an InvalidRecurrenceRuleException:

org.dmfs.rfc5545.recur.InvalidRecurrenceRuleException: RFC 2445 requires FREQ to be the first part of the rule: FREQ=WEEKLY;BYDAY=MO

It would be great if InvalidRecurrenceRuleException could be changed to be a RuntimeException so it does not have to be handled explicitly every time a rule String is parsed. I use validators before processing them, so an invalid rule is an application error in my case.

Hi! I found your library and it's just exactly what I need, but for some reason I can seem to create a correct RecurrenceRule.

This is what I'm writing:

RecurrenceRule rule = new RecurrenceRule(Freq.WEEKLY);

try {
    rule.setByPart(Part.INTERVAL, 1);
    Log.d(TAG, rule.toString());
} catch (InvalidRecurrenceRuleException e) {
   e.printStackTrace();
}

But this exception is thrown every time and I can't print a correct rule:

I'm using lib-recur-0.9.3.jar and following some sample code from this repo readme, I'll be grateful if you can point to a correct direction. Thanks!

In some use cases it might come in handy to be able to peek at the next instance without actually iterating it.

The following method will provide that feature:

/**
 * Peek at the next instance to be returned by {@link #next()} without actually iterating it.
 * Calling this method (even multiple times) won't affect the instances returned by {@link #next()}.
 * 
 * @return the upcoming instance or <code>null</code> if there are no more instances.
 */
public Calendar peek()

Hello!

I have the following rule:

FREQ=MONTHLY;BYDAY=FR;BYMONTH=3,6,9,12;BYSETPOS=-1

The rule describes an event that should occur on last Friday of March, June, September and December. The rule is correct - checked it with various tools.

For the start date of the iterator I set the first day of the 27th week of the year, which is: 07/06/2015.
The first date the iterator returns is the start date, which is clearly not the one described by the rule.

Assume I have a RecurrenceSet object named set and some arbitrary TimeZone object called timeZone.

If I call set.addExceptions("10290128T030720,2019127T030720", timeZone); and then get an iterator over the recurrence set, occurrences at both instances are excluded.

However, if I call set.addExceptions("10290128T030720", timeZone); followed by set.addExceptions("2019127T030720", timeZone); and then get an iterator over the recurrence set, only the first occurrence (at 10290128T030720) is excluded. The second one (at 10290128T030720) is still returned as an occurrence by the iterator.

Is this intended behavior? If so, how would I go about specifying EXDATEs taking place in multiple different time zones?

RecurrenceRule r11 = new RecurrenceRule("FREQ=WEEKLY;BYHOUR=10;COUNT=10", RecurrenceRule.RfcMode.RFC5545_LAX);
DateTime start = new DateTime(TimeZone.getTimeZone("America/Chicago"),2016, 1, 1,9,0,0);

RecurrenceRuleIterator rri = r11.iterator(start);
while(rri.hasNext()) {
        System.out.println(rri.nextDateTime());
}

Produces:

20160201T090000
20160201T100000
20160208T100000
20160215T100000
20160222T100000
20160229T100000
20160307T100000
20160314T100000
20160321T100000
20160328T100000

Hello. Is it possible to iterate over the events in reverse order? I don't see any code for this and RecurrenceRuleIterator seems to work only in one direction. If it's not possible, could you give me a hint how I could implement that myself?

Recurrence rule code that I am using is:
`
RecurrenceRule rule = null;

    TimeZone timeZone = TimeZone.getTimeZone("Asia/Dhaka");

    print(timeZone.toString());


    SimpleDateFormat formatter = new SimpleDateFormat("yyyyMMdd'T'HHmmss", Locale.US);

    String start = "20190603T000000";

    String end = "20190616T000000";

    DateTime startDateTime = new DateTime(DateUtils.getTimeInMilliseconds(start, formatter));

    DateTime endDateTime = new DateTime(DateUtils.getTimeInMilliseconds(end, formatter));

    try {
        rule = new RecurrenceRule("FREQ=WEEKLY;INTERVAL=1;WKST=MO;BYDAY=TU");
    } catch (InvalidRecurrenceRuleException e) {
        print(e.toString());
    }

    rule.setUntil(endDateTime);

    RecurrenceRuleIterator it = rule.iterator(startDateTime);

    int maxInstances = 100; // limit instances for rules that recur forever

    while (it.hasNext() && (!rule.isInfinite() || maxInstances-- > 0)) {
        DateTime nextInstance = it.nextDateTime();
        print(maxInstances + " -- " + nextInstance.toString());
    }

`

Expected results:

1 | Mon, | 03 | Jun | 2019 | 23:30:00 |
2 | Mon, | 10 | Jun | 2019 | 23:30:00 |

Result I am getting:

20190604T003000Z
20190611T003000Z

There is a hour difference between the results. Can you please help me in this regard?

The methods after(Calendar) and before(Calendar) should throw an Exception when comparing absolute and floating times. There is no point in doing that without providing the local time zone.

I have a list of rrules. Each rrule may have a DTSTART and UNTIL. But it seems that lib-recur RecurrenceSet does not support this, as it is assumed there is only one DTSTART for the set.

How can I use one DTSTART per rule in RecurrenceSet?

Given a time string with a freq > hourly, the BY[HOUR, MINUTE, SECOND] parameter is not interpreted correctly.

Example:

"FREQ=MONTHLY;UNTIL=20120131T120000;BYHOUR=12"

with the start date

"20120101T000000"

should result in 31 + 1 instances. However, only 2 instances are created.

Hi,

with this rule (BYSECOND missing): WKST=MO;FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SU;INTERVAL=1;BYHOUR=21;BYMINUTE=0;DTSTART=20161022T210000Z

the iterated occurrences have timestamps with invalid seconds value, for example 20161024T210048, should be 20161024T210000?

br,
Timo