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

RRuleSets don't handle DTSTART correctly #413

Open
topherauyeung opened this issue Jul 23, 2020 · 6 comments
Open

RRuleSets don't handle DTSTART correctly #413

topherauyeung opened this issue Jul 23, 2020 · 6 comments

Comments

@topherauyeung
Copy link

topherauyeung commented Jul 23, 2020

Reporting an issue

When using rrulestr to parse a set of rules, creating an RRuleSet and then enumerating its instances (or converting it to a string) is not working as expected.

The following code:

rrule.rrulestr(["RRULE:FREQ=DAILY;COUNT=2"].join("\n"), { dtstart: new Date(Date.UTC(2020, 6, 4, 0, 0)) }).toString()

produces:

'DTSTART:20200704T000000Z\nRRULE:FREQ=DAILY;COUNT=2'

while the following code:

rrule.rrulestr(["RRULE:FREQ=DAILY;COUNT=2",  "EXDATE:20600130T124000Z"].join("\n"), { dtstart: new Date(Date.UTC(2020, 6, 4, 0, 0)) 

unexpectedly produces:

'RRULE:FREQ=DAILY;COUNT=2\nEXDATE:20600130T124000Z'

and when inspecting the resultant RRuleSet, the dtstart parameter is not set correctly.

Notice that the DTSTART is missing entirely, because in the second example, rrulestr is producing an RRuleSet instead of an RRule. This bug also occurs if you pass forceset: true into the rrulestr options. This also manifests when calling .all() on the RRuleSet, which uses datetime.now() as the dtstart because it thinks that there wasn't one defined.

Version of rrule: 2.6.4
Operating system: MacOS High Sierra
Local timezone: PDT

@Noitidart
Copy link

Noitidart commented Sep 5, 2021

Confirming, I have the same problem. Took a long to figure this one out. It happens even without the forceset: true though. My problem:

rrulestr(`
RRULE:FREQ=WEEKLY;BYSECOND=0;BYDAY=MO;BYHOUR=15;BYMINUTE=0
RRULE:FREQ=WEEKLY;BYSECOND=0;BYDAY=TU;BYHOUR=15;BYMINUTE=0
RRULE:FREQ=WEEKLY;BYSECOND=0;BYDAY=SU;BYHOUR=15;BYMINUTE=0
`, { dtstart: new Date(Date.UTC(2021, 0, 1))} ).toString();

gives:

RRULE:FREQ=WEEKLY;BYSECOND=0;BYDAY=MO;BYHOUR=15;BYMINUTE=0
RRULE:FREQ=WEEKLY;BYSECOND=0;BYDAY=TU;BYHOUR=15;BYMINUTE=0
RRULE:FREQ=WEEKLY;BYSECOND=0;BYDAY=SU;BYHOUR=15;BYMINUTE=0

but what i expected was:

DTSTART:20210905T000000Z
RRULE:FREQ=WEEKLY;BYSECOND=0;BYDAY=MO;BYHOUR=15;BYMINUTE=0
DTSTART:20210905T000000Z
RRULE:FREQ=WEEKLY;BYSECOND=0;BYDAY=TU;BYHOUR=15;BYMINUTE=0
DTSTART:20210905T000000Z
RRULE:FREQ=WEEKLY;BYSECOND=0;BYDAY=SU;BYHOUR=15;BYMINUTE=0

@Noitidart
Copy link

I wrote a workaround until then, it requires moment.

function getSetFromTimeRule(timeRule, options = {}) {
  let dtstartStr = '';
  if (options.dtstartMoment) {
    dtstartStr =
      'DTSTART:' + startWeekMoment.format('YYYYMMDD[T]HHmmss[Z]') + '\n';
  }

  const set = rrulestr(dtstart + timeRule);

  return set;
}

@PanMan
Copy link

PanMan commented Dec 13, 2021

Thanks! I had the same issue: setting dtstart via the rrulestr options didn't work: I got dates before the DTSTART in the result.
The fix above by @Noitidart does work, but seems a workaround for broken functionality.

@Noitidart
Copy link

Agreed, I really dont like my work around. I should remove moment from it too, its too much for others that use it and dont have moment installed.

@morgan-wowk
Copy link

Hey folks,

I had this issue when using the rrulestr function with an RRULE that contained an EXDATE. The solution for me was to prefer using parsedRule.dtstart() and parsedRule.tzid(). I now fallback to what I was previously using (broken) which is parsedRule.options.dtstart and parsedRule.options.tzid.

It seems that the callable functions (which I hope are always present) work more reliably than accessing the options.

@NOPR9D
Copy link

NOPR9D commented Mar 24, 2023

So ? No news ?

giphy (11)

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

5 participants