[Tickets #10194] Re: Kronolith does not sync calendar, contacts work with Android 2.2.1/Motorola Milestone mobile

[bugs at horde.org]

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

Ticket URL: http://bugs.horde.org/ticket/10194
------------------------------------------------------------------------------
  Ticket             | 10194
  Updated By         | Michael Rubinsky <mrubinsk at horde.org>
  Summary            | Kronolith does not sync calendar, contacts work with
                     | Android 2.2.1/Motorola Milestone mobile
  Queue              | Synchronization
  Version            | Git master
  Type               | Bug
-State              | Not A Bug
+State              | Assigned
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             | Michael Rubinsky
------------------------------------------------------------------------------


Michael Rubinsky <mrubinsk at horde.org> (2011-07-05 23:06) wrote:

Reopening during the time I am trying to track this down to something  
that can be either submitted to PHP as a bug report, or something in  
Horde_Date that can get fixed. After some irc debugging with a user  
who is experiencing this issue, we have come to the following:

The following *does* experience the issue on a debian lenny server:

$d = new Horde_Date('2011-07-08 15:00:00', 'Europe/Zurich');
$tz = $d->toDateTime()->getTimezone();
var_dump($tz);
var_dump($tz->getName());
var_dump($tz->getTransitions());
echo 'foobar';

The code dies at the $tz->getTransitions() line. In this case, the  
getName() call just returned an empty string.

If we break out the lower level code from Horde_Date that is actually  
being executed:

$date = new DateTime(null, new DateTimeZone('Europe/Zurich'));
$date->setDate(2011, 07, 08);
$date->setTime(15, 0, 0);
$tz = $date->getTimezone();
var_dump($tz);
var_dump($tz->getName());
var_dump($tz->getTransitions());
echo 'foobar';

*this* code runs without issue. This is the exact same code that is  
executed, with (supposedly) the same values, as is run by using  
Horde_Date. Something in Horde_Date is causing things to get mucked up.

Both scripts execute fine on a number of local servers, as well as the  
reporter's Debian Squeeze server