Thanks for the patch, Andreas - I've just committed it.

Hi, here is a patch which solves the problem. Please apply ASAP.

Hi Horde team, can anyone outline possible solutions for the timezone 
problem? I'm willing to test some variants, otherwise you can't use 
Horde if you don't use GMT / UTC.

Regards,

Andreas

I've tried mktime, but without success: What I have found in the 
meantime is the need to fix kronolith/lib/Driver/kolab.php in function 
saveEvent($event) around line 180 like this:



         $k->setVal('alarm', $event->getAlarm());

         if ($event->isAllDay()) {

             $k->setVal('start-date', 
Kolab::encodeDate($event->start->timestamp()));

             $k->setVal('end-date', 
Kolab::encodeDate($event->end->timestamp()));

         } else {

             $k->setVal('start-date', 
Kolab::encodeDateTime($event->start->timestamp()));

             $k->setVal('end-date', 
Kolab::encodeDateTime($event->end->timestamp()));

         }



         switch ($event->status) {



This is because the Kolab XML format expects date-only values for 
events with a duration of a whole day.



However this increases the timezone problem. In function 
encodeDate($date = false) in framework/Kolab/kolab.php there I find 
time values like 2005-04-20T22:00:00Z for GMT+2 midnight, but this is 
2005-04-21 (00:00) in our time. Reducing the values 
2005-04-20T22:00:00Z and 2005-04-21T22:00:00Z to the date gives 
2005-04-20 and 2005-04-21 instead of 2005-04-21 two times. :-(

So I end up with a two day long event instead of one day.

A possible solution would be to use mktime() instead of gmmktime(), 
but this method might be used in different places where we explicitely 
expect GMT dates. Stuart, you probably know this off your head.

There is a problem in the Kolab class in:

     function decodeDate($date)

     {

         if (empty($date)) {

             return 0;

         }



         list($year, $month, $day) = explode('-', $date);

         return gmmktime(0, 0, 0, $month, $day, $year);

     }



The problem is that assuming "0, 0, 0" as midnight is wrong here. The 
events created by other Kolab 2 clients having entries like 
<start-date>2005-04-22</start-date> show up from 2am to 2am at the 
next day due to our GMT+2 (daylight saving) timezone.