[horde] ActiveSync -> CalDAV Timezone problems

[Michael J Rubinsky]

Quoting Michael J Rubinsky <mrubinsk at horde.org>:

> 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.

A more detailed explanation for the record:

EAS does not use timezone names/aliases at all. It only uses a single  
set of transition dates that describe the timezone. It's up to the  
client/server to translate that into timezone data it can use. For  
Horde/PHP this means we have to translate it into a "standard"  
identifier (as used in the Olson database). The reasons that this is a  
broken design is a different discussion altogether.

Anyway, the problem here is that since all we have is a SINGLE set of  
transition times, there will almost always be multiple timezone names  
that will match when attempting to map the transitions to known zones.  
This is why we check if we have an expected timezone and return it if  
it's in the list of matched zones. What's happening for you is that  
since the timezone data is incorrect for your expected timezone it's  
not in the list so we return the more generic timezone  
alias/abbreviation - CET in your case. FWIW, anytime there is an event  
in a timezone that is different from date_default_timezone this will  
happen. So, while in your case the CET being returned is the result of  
broken client data - it's not an unexpected value to be returned.

For Horde 6 we could look at returning the full list of matching  
timezones and let the calling code be responsible for picking the best  
match. This might be more flexible, but still wouldn't help in this  
case - we still would have no idea which Olson timezone name is  
correct so the abbreviated alias would be the better choice.

-- 
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/8df0b1ed/attachment-0001.bin>