Ical.parse returns RRULE with WKST as a number, not a string as in RFC 7265

[moll]

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 of RRULE's WKST 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

[kewisch]

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.

[moll]

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.

[moll]

I clarified the title a little, too.

[kewisch]

Ah yes, sorry I misread! In that case this sounds like a valid bug!

[kewisch]

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.

[github-actions[bot]]

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.