Closed moll closed 3 months ago
ICAL.parse()
is supposed to parse rfc5545 or rfc6350 data. If you already have jCal data, you can just use new ICAL.Component(jcaldata)
; I'm surprised ICAL.parse
would parse jcal data, I guess it would be smart to throw in this case.
Correct me if I'm wrong, but isn't Ical.parse supposed to parse to a jCal (RFC 7265) compatible object?
I am giving it a string in RFC 5545. What I mean is that the RFC 7265 format it returns (hence the "to a" in the sentence above") isn't RFC-compatible because of the numeric WKST
.
I clarified the title a little, too.
Ah yes, sorry I misread! In that case this sounds like a valid bug!
Ok, many years later I've taken a look at this. Technically what happens is correct. ICAL.parse
will create an ICAL.Recur
object, which has a wkst
member, but that is not expected to be a string. I can imagine the reasoning was that numbers are quicker to compare, though you could argue the string/number conversion eats it up in some situations.
If you call recur.toJSON()
you will get a valid rfc7265 part of the jCal that uses a string for the wkst.
If there is something we can improve in the documentation around this let me know.
It looks like we haven't heard back on this issue, therefore we are closing this issue. If this problem persists in the latest version of ical.js, please re-open this issue.
Hey,
Correct me if I'm wrong, but isn't
Ical.parse
supposed to parse to a jCal (RFC 7265) compatible object? It seems to do so with the exception ofRRULE
'sWKST
which is returned as number and not a string as the RFC states. This just tripped me up, especially because it's a peculiar offset-from-1 enum.Cheers