Skip to content
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

Returns the StartDate even if not applicable #12

Open
GoogleCodeExporter opened this issue Mar 1, 2016 · 1 comment
Open

Returns the StartDate even if not applicable #12

GoogleCodeExporter opened this issue Mar 1, 2016 · 1 comment

Comments

@GoogleCodeExporter
Copy link

Hi, a lot of different RRULEs that I've tried returns me the start date.
The rule below is just an example.
Most of the examples from https://tools.ietf.org/html/rfc2445#section-4.8.5.4 
fails due to a returning startdate.

private static void runGoogleTests() throws ParseException
{
    DateTimeZone dtz = DateTimeZone.UTC;
    DateTime dtStart = new DateTime("2014-11-22T00:00:00Z", dtz);//SATURDAY
    DateTimeIterable dti = DateTimeIteratorFactory.createDateTimeIterable("RRULE:FREQ=WEEKLY;COUNT=10;BYDAY=MO", dtStart, dtz, true);

    System.out.println("Size of iterable = " + Iterators.size(dti.iterator()));
    for(DateTime dateTime : dti)
    {
        System.out.println(dateTime);
    }
}

What is the expected output? What do you see instead?
The expected output is a 10 dates that is only Mondays.

Output
Size of iterable = 11
2014-11-22T00:00:00.000Z  <-- Start date is Saturday
2014-11-24T00:00:00.000Z
2014-12-01T00:00:00.000Z
2014-12-08T00:00:00.000Z
2014-12-15T00:00:00.000Z
2014-12-22T00:00:00.000Z
2014-12-29T00:00:00.000Z
2015-01-05T00:00:00.000Z
2015-01-12T00:00:00.000Z
2015-01-19T00:00:00.000Z
2015-01-26T00:00:00.000Z

Original issue reported on code.google.com by [email protected] on 24 Nov 2014 at 1:15

Attachments:

@GoogleCodeExporter
Copy link
Author

from RFC 5545:
"The "DTSTART"
      property value SHOULD match the pattern of the recurrence rule, if
      specified.  The recurrence set generated with a "DTSTART" property
      value that doesn't match the pattern of the rule is undefined."

note: "Should" is not "Must". The second part implies that an implementation 
Can decide to return it or ignore it if doesn't match.

Original comment by [email protected] on 20 Jul 2015 at 4:27

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

No branches or pull requests

1 participant