There are several pending proposals to change the recurrence syntax to make it clearer. (There is a list of issues on rfc 2445). The rest of this section will summarize the discussions on recurrence on the ietf-calendar mailing list.
Doug Royer asks:
Can a VEVENT have a:
- DTSTART with a date-time value
- a RRULE of FREQ=WEEKLY (or any other FREQ)
- a RDATE with a value of date (not date-time)
Off of the top of my head I would say yes.
Dan Hickman agrees:
I think it should be an acceptable option. The current spec does not define this as an error state and we can't be sure that there isn't some use for it. It is conceivable that a user could have a need for an event where one occurrence needs to be tied to a specific time but another does not.
Frank Dawson however disagrees:
Then these are definitely two different events! A recurring event is one that occurs multiple times. Certainly, they may vary in the start or end time, but if they are repetitions of the same event, then they should have some commonality.
No, this is an error UNLESS the semantics are that when this occurs, it is a short-hand for “take the time portion of the date/time” from the original DTSTART and DTEND.
Other wise, there appears to be a value type mismatching here
Dan Hickman replies:
I don't think your short-hand suggestion would be the right way to interpret it. Either it is an error case or you can indeed have DATE occurrences in a DATE-TIME event (and vice-versa).
I agree that this would be a wierd type of event, but the spec doesn't specifically disallow it and I don't think we should eliminate the option to provide that functionality.
Frank Dawson replies to that with:
If you had a recurrence where the DTSTART and DTEND were of DATE-TIME value types and the RDATE/EXDATE were with DATE value type, you could assume the “TIME” piece for the RDATE/EXDATE values were to be the same as that in the DTSTART/DTEND. This is much more appropriate than allowing conflicting value types in the DTSTART/DTEND and RDATE/EXDATE.
For example, what do you do with the VALARMs for those occurences specified by the RDATE values? Should that repeating alarm really go off at 9:00 AM after all? This is one reason why strong, consistent “value typing” across the DTSTART, DTEND or DURATION, RDATE, EXDATE and RECURRENCE-ID needs to be a MUST! This was the intent of the iCalendar specification. Fine, we need to clarify the text in iCalendar.
Dan Hickman gives in:
That is fine by me if everyone else agrees.
Does everyone agree that date type (DATE or DATE-TIME) must be consistent for all values in an event?
The issue seems closed until a query by Damon Chaplin:
I'm a bit unsure of the semantics of UNTIL/RDATE/EXDATE recurrence properties that have DATE values (as opposed to DATE-TIME values).
If only a DATE is given, do you just assume that the time is 00:00:00, or do you do something more. For example
If an UNTIL property has a DATE value does it mean:
- until 12 am on that date (i.e. you just assume 00:00:00).
- until the last occurrence on that date (i.e. you take it as 23:59:59).
If an RDATE property has a DATE value does it mean:
- an occurrence on 12 am on that date.
- an occurrence at the same time as the initial occurrence, but on the given date.
If an EXDATE property has a DATE value does it mean:
- exclude any occurrence at 12 am on that date.
- exclude all occurrences on that date.
I think all the (b) answers are more intuitive but I don't think the iCalendar spec is specific about these.
John Stracke suggests disallowing DATE values for the properties involved (UNTIL, RDATE and EXDATE) altogether. He also wonders what the original reason for permitting them was.
Bruce Kahn replies that you can have a component with DATE values for all the time related properties, and gives an example case where allowing a DATE value on EXDATE is useful:
Another use is to block out (in the case of EXDATES) all instances of a repeat set that occur on a particular day. For example, a movie shows ~4-6 times a day but the theatre will be closed on New Years Day so they want to exclude ALL instances on that date.
Also, dont forget that we declared (somewhere, honest!) that times are inherited from the DTSTART/DTEND (or DURATION) if none are specfied on the RDATE, EXDATE (and probably implied on the UNTIL too but Im not sure).
John Stracke is not convinced:
These two statements are inconsistent. An EXDATE with no time can't both default to the same time as DTSTART and be a wildcard.
He suggests to mandate that all the date/time related properties used for calculating the recurrence in a component be the same type, either DATE-TIME or DATE.
Bruce Kahn claims there was earlier discussion on this, where there was a concensus reached on recurrence exception properties having special semantics when they have a DATE type:
The concensus reached was basically:
RDATEs inherit the exact time from the DTSTART. If DTSTART has VALUE=DATE then the implied 00:00:00 is inherited.
EXDATEs do not inherit exact times if they are VALUE=DATE. By covering ANY AND ALL instances on that date they effectively achieve “excluding the date” w/o worrying about any RRULE instances that are generated (ie: FREQ=DAILY;BYHOUR=9,10,11;BYMIN=00,30,...). Excluding specific instances is done via VALUE=DATE-TIME.
The gist of this decision was that if something repeats daily then excluding “all that day” works just as well as inheriting the time from the DTSTART. If it repeats “sub daily” (see theatre example) then it is much simpler to block an entire day by this means than using an EXRULE or several EXDATEs that may not catch any changes in the recurrence set (ie: rescheduling one showing to accomodate a private party). To exclude a particular instance on a “sub daily” recurrence would invovle using DATE-TIMEs to be more precise.
John Stracke is satisfied with this, and Eric Busboom sends in a proposal to change the rfc. This is accepted.