Forum OpenACS Development: Re: Confusing calendar behavior with recurring events.

Posted by Gustaf Neumann on
Let me rephrase: One has a recurring event (e.g. for April, starting every day at 9am), and changes just for April 7 the starting date to 9:30 (no recurrence). So far, everything is fine.

If now someone alters the recurring event to 10am, starting with April 1, then every day will have the starting time 10am, except April 7, which has now 10:30. This is not expected and happens due to the relative time change in the implementation.

However, the current implementation cares for DST shifts. If within a recurring event the DST changes, then it can be the case that for a few days, the starting time is e.g. 9am and for some later events, it is 10am). In an international setup, this might be the right thing (people in other timezones might have no idea, when the timezones of their partners changes). However, for a local setup (e.g. starting time of a course), this does not make sense, since the course will effectively starts e.g. one hour earlier due the DST shift. The recurring rule should have actually a flag, stating universal time or localtime).

Dave, your suggestion will kill the DST shift feature. In my point of view, the defensible semantics for the above situation (rule + 1 day exception) is: if the rule changes, leave out the events which are out of the recurring rule (which got separate times). This means, change just the events, for which the actual start and end times are equal to those generated by the original recurrence rule. I see this from the classic AI (or OO) point of view: The rule says, start every day at time X. There is an exception on April 7, therefor the fact. If the rule changes, nothing is said about the exception.

However, there is an second problem with the implementation of the recurring events: suppose, in the above example, we go to April 20, and we edit this entry and alter its start time to 11am (with recurrences).

The effect of the current implementation is that the older dates of the rule (before April 20) are effected as well (even dates in the past, one cannot change events, that already have happened). This is as well unexpected behavior. I think, a defensible semantics would be that the change on April 20 ends the old recurrence rule and start a new one with the altered dates.