Forum OpenACS Development: Confusing calendar behavior with recurring events.

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.

The idea of a recurring event having a flag, local or universal time is interesting. Really all events should have that. Right now, I believe events are stored with the system timezone exclusively. But only on PostgreSQL. No timezone data is stored on Oracle installs.

Probably the correct behavior is to allow setting the timezone of the event for every event. Then the local time of the event could be chosen and could be displayed in the calendar.

There is an almost infinite number of ways to tweak the behavior of the calendar. It all depends on what a user expects. I am basically comparing other calendar software, hoping those developers have done the research into what is best for most users.

Dave, i am confused by your statements as well.

My users are stating that during standard time and DST the event's time does not change

The event's time of recurring events? Maybe we have missed an update, but the behavior of our large installation is exactly as i described: I added a recurring event for every day starting on march 1 running until end of April at 8am. The generated events are from April 1 to April 24 at 8 am, then starting at March 25 (when our DST started) it switches to 9am until end of April.

But real people couldn't care less.

It depends: in an international setup this makes perfectly sense. It is actually the only possible way, when e.g. three people in three different time-zones work together. These real people don't care about the time-zones the other people are in, but they want to meet in a chat at the same time.

So I am just reporting that I had users complain that their evets mysteriously changed time on March 11

Three paragraphs earlier, you state that the events time did not change. Are you saying, that recurring events did not change, but single events changed their time?

So issues in acs-events and calendar are

1) Oracle does not store timezone data
2) PostgreSQL stores timezone data, but the user can never set the timezone. It uses the system timezone of the operating system/PostgreSQL
3) Individually edited recurring events result in inconsistent behavior, the system is not coded to handle them in any way.
4) The system never displays the timezone, especially if its different than the currently displayed timezone.
5) You can't edit only future events in calendar ( I have code to fix this, the acs-events part is checked into CVS. The UI changes can go in anytime.)
6) recurring events across DST boundaries change time when they should not. (This is fixed for new installs as of 5.2, and upgrades from oacs-5-3 cvs acs-events package )

Anything else?

These are seperate but interconnected issues. Fixig one can change the behavior of the other issues in unexpected ways. We need to define what acs-events, and the calendar package are supposed to

I'll have to test some more example calendar packages. I checked, Google Calendar, for one, and editing a recurring event time resets the time for all instances of the event. Yahoo calendar behaves the same way. I don't have any other calendar software handy. If anyone can test on Outlook or Palm OS calendars, that would be useful.