-
-
Notifications
You must be signed in to change notification settings - Fork 519
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
RRuleSet
s don't handle DTSTART
correctly
#413
Comments
Confirming, I have the same problem. Took a long to figure this one out. It happens even without the
gives:
but what i expected was:
|
I wrote a workaround until then, it requires moment.
|
Thanks! I had the same issue: setting |
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. |
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 It seems that the callable functions (which I hope are always present) work more reliably than accessing the options. |
Reporting an issue
When using
rrulestr
to parse a set of rules, creating anRRuleSet
and then enumerating its instances (or converting it to a string) is not working as expected.The following code:
produces:
while the following code:
unexpectedly produces:
and when inspecting the resultant
RRuleSet
, thedtstart
parameter is not set correctly.Notice that the
DTSTART
is missing entirely, because in the second example,rrulestr
is producing anRRuleSet
instead of anRRule
. This bug also occurs if you passforceset: true
into therrulestr
options. This also manifests when calling.all()
on theRRuleSet
, which usesdatetime.now()
as thedtstart
because it thinks that there wasn't one defined.Version of rrule: 2.6.4
Operating system: MacOS High Sierra
Local timezone: PDT
The text was updated successfully, but these errors were encountered: