[horde] [ActiveSync][Kronolith][CentOS 7] wrong event start and end

[0x90]

Hi,

I did set up a new installation of Horde on CentOS 7.2 and have  
troubles with activesync/calendar.
Using Outlook 2013 as a activesync client causes wrong entries in  
kronolith_events (event_start and event_end) when adding a new all day  
event.
This is problematic, because outlook clients will crash if they see an  
event that they did not create (e.g. shared calendar or new instance  
of activesync client).
I have a installation with pretty much same configuration on a CentOS  
6.7, which is working correct.

Here some infos:

# versions:
horde 5.2.9
kronolith 4.2.15
activesync 2.31.6


# config/prefs.d/10-myprefs.php

$_prefs['timezone'] = array(
     'value' => 'Europe/Berlin'
     [...]


# kronolith/config/conf.php

$conf['calendar']['params']['utc'] = true;
$conf['resource']['params']['utc'] = true;


# /etc/php.ini

date.timezone = Europe/Berlin


# output from horde php shell

every context gives correct time and timezone when executing "echo  
date("H:i:s").date_default_timezone_get();"


# activesync log (adding a new event in Outlook 2013 for 2016-03-14,  
whole day)
[...]
DEBUG: [1872] I        <POOMCAL:StartTime>
DEBUG: [1872] I          20160313T230000Z
DEBUG: [1872] I        </POOMCAL:StartTime>
[...]
DEBUG: [1872] I        <POOMCAL:EndTime>
DEBUG: [1872] I          20160314T230000Z
DEBUG: [1872] I        </POOMCAL:EndTime>
[...]


# mysql dump of kronolith_events on both systems after event added  
over activesync by outlook

# System1: CentOS 6.7, Apache 2.2.15, PHP 5.3.3 (correct):

event_start=2016-03-14 00:00:00
event_end=2016-03-15 00:00:00
event_allday=1

# System2: CentOS 7.2, Apache 2.4.6, PHP 5.4.16, SELinux: no (incorrect):

event_start=2016-03-13 23:00:00
event_end=2016-03-14 23:00:00
event_allday=1


# additional info from php changelog
# ( https://secure.php.net/manual/en/migration54.incompatible.php )

"In the date and time extension, the timezone can no longer be set  
using the TZ environment variable. Instead you have to specify a  
timezone using the date.timezone php.ini option or  
date_default_timezone_set() function. PHP will no longer attempt to  
guess the timezone, and will instead fall back to "UTC" and issue a  
E_WARNING."



I hope you can give me a hint what to do.

greetings,
0x90