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

* Your Email Address
* Spam protection	Enter the letters below: . .. ..__..___.\ / \| \|\ /[__] \| >< \|__\| \/ \| \| \| / \
Comment	> 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. > >
Attachment
Watch this ticket

Saved Queries