Toke Høiland-Jørgensen <t...@toke.dk> writes: > Michael Brand <michael.ch.br...@gmail.com> writes: > >> When implementing this, consider also whether the END_DATE should be >> an agenda entry on its own and of which kind, warning period etc. I >> tried to make an example that shows this issue. > > Adding to this, as mentioned previously, I interpret the iCal standard > to really permit and end *time* rather than an end *date*. Which would > make more sense in an org context? Going for an END_TIME parameter, and > then comparing exactly to the scheduled time (i.e. if current iteration > of the recurring entry > END_TIME, then filter it), or doing an END_DATE > and then interpreting the actual cut-off to be at 00:00:00 on that > date?
I think it would be less ambiguous to use ICALENDAR_UNTIL (or UNTIL), and apply RFC 5545: The value of the UNTIL rule part MUST have the same value type as the "DTSTART" property. Furthermore, if the "DTSTART" property is specified as a date with local time, then the UNTIL rule part MUST also be specified as a date with local time. If the "DTSTART" property is specified as a date with UTC time or a date with local time and time zone reference, then the UNTIL rule part MUST be specified as a date with UTC time. Regards, -- Nicolas Goaziou
