[Tickets #7038] timezone and recurrence fixes for Kronolith's scheduler

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/7038
------------------------------------------------------------------------------
  Ticket             | 7038
  Created By         | develop at kristov.de
  Summary            | timezone and recurrence fixes for Kronolith's scheduler
  Queue              | Kronolith
  Version            | 2.2
  Type               | Bug
  State              | Unconfirmed
  Priority           | 2. Medium
  Milestone          |
  Patch              | 1
  Owners             |
+New Attachment     | horde-kronolith-2.2-scheduler-1.patch
------------------------------------------------------------------------------


develop at kristov.de (2008-07-06 17:01) wrote:

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.