[horde] ActiveSync -> CalDAV Timezone problems

Michael J Rubinsky mrubinsk at horde.org
Fri Mar 18 03:07:37 UTC 2016


Quoting Steffen <skhorde at smail.inf.fh-bonn-rhein-sieg.de>:

> On Wed, 16 Mar 2016, Michael J Rubinsky wrote:
>> Quoting Jan Schneider <jan at horde.org>:
>>
>>> Zitat von Jan Schneider <jan at horde.org>:
>>>
>>>> Zitat von Steffen <skhorde at smail.inf.fh-bonn-rhein-sieg.de>:
>>>>
>>>>> Hi,
>>>>>
>>>>> with
>>>>> Horde_ActiveSync             2.31.6  stable
>>>>> kronolith                    4.2.15  stable
>>>>>
>>>>> when I create an event with Android ActiveSync, I get an entry  
>>>>> with event_timezone = 'CET' in the database; the GUI and  
>>>>> ActiveSync display the event correctly. But when downloaded by  
>>>>> CalDAV I get this:
>>>>>
>>>>> BEGIN:VCALENDAR
>>>>> VERSION:2.0
>>>>> X-WR-CALNAME:Calendar of dvtest1
>>>>> PRODID:-//The Horde Project//Horde iCalendar Library//EN
>>>>> BEGIN:VEVENT
>>>>> DTSTART;TZID=CET:20160308T150000
>>>>> DTEND;TZID=CET:20160308T153000
>>>>> DTSTAMP:20160314T123714Z
>>>>> UID:20160314132443.4C_Xp8mUFWBF6GsNZi0nVRb at ...
>>>>> CREATED:20160314T122443Z
>>>>> LAST-MODIFIED:20160314T122443Z
>>>>> SUMMARY:B15:00
>>>>> CLASS:PUBLIC
>>>>> STATUS:CONFIRMED
>>>>> TRANSP:OPAQUE
>>>>> BEGIN:VALARM
>>>>> ACTION:DISPLAY
>>>>> DESCRIPTION:B15:00
>>>>> TRIGGER;VALUE=DURATION:-PT15M
>>>>> END:VALARM
>>>>> END:VEVENT
>>>>> BEGIN:VTIMEZONE
>>>>> TZID:CET
>>>>> END:VTIMEZONE
>>>>> END:VCALENDAR
>>>>>
>>>>> My client is totally confused by the timezone CET. If I replace  
>>>>> the string CET by "Europe/Berlin" in the database, I get the  
>>>>> correct date in the CalDAV client, too, and a lot more entries  
>>>>> in VTIMEZONE.
>>>>>
>>>>> The user has Europe/Berlin as default timezone, as does PHP.
>>>>>
>>>>> Is this some configuration error?
>>>>> If I remember correctly, ActiveSync storred UTC as timezone, didn't it?
>>>>>
>>>>> -- 
>>>>> Steffen
>>>>
>>>> Looks like starting with PHP 5.5.10 DateTimeZone no longer  
>>>> converts timezone abbreviations to full timezone names, which is  
>>>> of course a big BC break. We would have to work around this.
>>>
>>> OTOH we don't import unknown timezones anyway, at least not via  
>>> iCalendar import. But maybe we do this differently with  
>>> ActiveSync. Michael does know better.
>>
>> Timezones from ActiveSync clients are presented in an MAPI encoded  
>> binary format that describes the timezone instead of naming it. We  
>> use DateTimeZone::listIdentifiers to retrieve the list of supported  
>> timezones when parsing the MAPI data to determine the  
>> matching/supported timezone name. So, if the timezone name comes  
>> from ActiveSync it means is MUST have been returned by DateTimeZone.
>
> Horde/Mapi/Timezone.php
>
>    public function getTimezone($offsets, $expectedTimezone = null)
>    {
>        $timezones = $this->getListOfTimezones($offsets, $expectedTimezone);
>
> ska_dumpvar('Mapi/getTimezone() = ', array("offsets" => $offsets,  
> "expect" => $expectedTimezone, "tz" => $timezones));
>
>        if (isset($timezones[$expectedTimezone])) {
>            return $expectedTimezone;
>        } else {
>            return current($timezones);
>        }
>    }
>
>
> has:
>
> Mapi/getTimezone() =
> array(3) {
>  ["offsets"]=>
>  string(232)  
> "xP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAAAFAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAEAAIAAAAAAAAAxP///w=="

If you are 100% sure the client is configured for the correct timezone  
then the blob your client is sending for Europe/Berlin is incorrect.  
The CORRECT blob for Europe/Berlin would be (There is a one character  
difference towards the end - a "F" in place of the "E" your client is  
sending):

'xP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAAAFAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAFAAIAAAAAAAAAxP///w=='

This difference translates to the DSTMONTH value being set to 4  
instead of 5. This is incorrect for Europe/Berlin as the transition  
occurs on the LAST Sunday of the month (which is what the 5 means) and  
NOT explicitly on the 4th Sunday.


-- 
mike
The Horde Project
http://www.horde.org
https://www.facebook.com/hordeproject
https://www.twitter.com/hordeproject
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5751 bytes
Desc: S/MIME Signature
URL: <http://lists.horde.org/archives/horde/attachments/20160317/a190f7e7/attachment.bin>


More information about the horde mailing list