Sorry for my late posting, I'm currently finishing my PhD thesis and 
there's quite a lot to do yet... Anyway, your fix works for me, thank 
you!

Tweaked and committed. Please test the version I checked in.

Changes have been made in CVS for this ticket:

http://cvs.horde.org/diff.php/kronolith/lib/Scheduler/kronolith.php?r1=1.25.6.21&r2=1.25.6.22&ty=u

When the server and the Horde users use different timezones (in my 
case, UTC vs. Europe/Berlin), and the Kronolith scheduler is used 
(instead of the Horde Alarm system), strange things occur. In my case, 
many events were scheduled twice, once on time and once two hours 
later (the timezone difference between UTC and Europe/Berlin summer 
time). There also was an interaction with the agenda code which set 
the 'TZ' environment variable and inadvertantly changed the PHP's 
timezone for the following date calculations in the scheduler; as the 
agenda() function was not called every time, it was close to 
undeterminable when an event is scheduled correctly and when it is 
scheduled twice.



So I rewrote the scheduler in the spirit of the agenda function, i.e. 
I changed the outer and the inner loop of the scheduler: The outer 
loop iterates on the users, and the inner loop iterates on the events 
of the shares visible to the user. This allows to set the timezone for 
each user according to her stored preference before accessing the 
events.



The second problem the patches fixes is a bug introduced in rev. 1.55 
of lib/Scheduler/kronolith.php. As the revision comment correctly 
says, "Recurrence processing happens in listAlarms() now", so code was 
removed which handled recurrences via nextRecurrence() and 
hasException(). However, listAlarms() is called with fullevent==false, 
such that only the event *ids* and not the events (with corrected 
start/end time) are returned. So when the event is later retrieved via 
getEvent():



$event = $GLOBALS['kronolith_driver']->getEvent($eventId);



the recurrence corrections are gone. My solution simply reactivates 
the old correction code:



                             /* Set the event's start date to the next

                              * recurrence date. This should avoid problems

                              * when an alarm triggers on a different day from

                              * the actual event, and make $seenid unique for

                              * each occurrence of a recurring event. */

                             $event->start = 
$event->recurrence->nextRecurrence($this->_runtime);



                             /* Check for exceptions; do nothing if 
one is found. */

                             if 
($event->recurrence->hasException($event->start->year, 
$event->start->month, $event->start->mday)) {

                                 continue;

                             }



Another solution would be to rewrite this part of scheduler to use 
fullevent==true and to omit the getEvent() call. I can try that if you 
think that this would be the better solution.