Closed ghost closed 2 years ago
Hm, may I ask why you need this setter? IIRC I intentionally left it out because it was ill-defined.
Do not set the TZID property parameter, as the RFC specifies.
Can you reference where the RFC mentions this?
Hm, may I ask why you need this setter? IIRC I intentionally left it out because it was ill-defined.
It would be convenient to support all day events in alps.
However, it's not necessary to have this abstraction in the library.
Could you explain why you find DATE
is ill-defined?
Can you reference where the RFC mentions this?
It is my interpretation of section 3.2.19:
The "TZID" property parameter MUST NOT be applied to DATE properties and DATE-TIME or TIME properties whose time values are specified in UTC.
all day events
Ah, right, that makes sense.
It is my interpretation of section 3.2.19:
Hm, I missed this section of the RFC when implementing Prop.DateTime
it seems. The function uses TZID
even for DATE
values.
Hm, I missed this section of the RFC when implementing
Prop.DateTime
it seems. The function usesTZID
even forDATE
values.
I noticed it as well. I can attempt to fix it in a future commit.
I kept the date formats local as before and will make all of them global in the next PR. No more changes from me until you have further comments.
Add a setter for the
DATE
value type. Do not set theTZID
property parameter, as the RFC specifies.