Re: [O] Adding support for limits and exclusions to iCal recurring events

[Nicolas Goaziou]

Toke Høiland-Jørgensen <address@hidden> writes:

> Michael Brand <address@hidden> 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