[horde] Can't add Outlook meeting request to Kronolith

[Simon Brereton]

On 10 January 2013 12:02, Michael J Rubinsky <mrubinsk at horde.org> wrote:
>
> Quoting Simon Brereton <simon.buongiorno at gmail.com>:
>
>> On 9 January 2013 23:58, Simon Brereton <simon.buongiorno at gmail.com>
>> wrote:
>>>
>>> On 9 January 2013 16:42, Brent <impuser at bitrealm.com> wrote:
>>>>
>>>>
>>>> Quoting Michael M Slusarz <slusarz at horde.org>:
>>>>
>>>>> Quoting Oscar del Rio <delrio at mie.utoronto.ca>:
>>>>>
>>>>>> On 01/ 8/13 03:07 PM, Michael M Slusarz wrote:
>>>>>>>
>>>>>>>
>>>>>>> "W. Europe Standard Time" is not a valid timezone, as the error
>>>>>>> message
>>>>>>> indicates.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Similar error when accepting event invitations from Exchange users but
>>>>>> with "Eastern Standard Time" here.
>>>>>>
>>>>>> HORDE: [ID 702911 user.emerg] [kronolith] DateTimeZone::__construct():
>>>>>> Unknown or bad timezone (Eastern Standard Time) on line 285 of
>>>>>> "/var/php/5.3/pear/Horde/Date.php"
>>>>>
>>>>>
>>>>>
>>>>> That also isn't a valid POSIX/GNU C-ish timezone (a/k/a from the
>>>>> tz/zoneinfo DB: http://www.twinsun.com/tz/tz-link.htm).
>>>>>
>>>>> These are the only timezones supported by PHP and, for that matter,
>>>>> most
>>>>> software: http://php.net/manual/en/timezones.php
>>>>>
>>>>> It *appears* that these are Windows tzid's, which are not supported.
>>>>> Someone will need to write conversion software to map to a valid TZ.
>>>>> See,
>>>>> e.g.,
>>>>>
>>>>> http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/zone_tzid.html
>>>>>
>>>>
>>>>
>>>> I THOUGHT it worked at one point, but now it doesn't.  I am getting the
>>>> timezone error.  The TZID is being set by the remote Exchange server and
>>>> not being handled by Horde.  Same calendar event works to gmail/yahoo,
>>>> but Horde complains:
>>>>
>>>> Unknown or bad timezone (Pacific Standard Time)
>>>>
>>>>
>>>> So, three parts are mime-encoded in the Calendar request sent from
>>>> Outlook
>>>> though an Exchange server.  There is a .calendar file, a .html file, and
>>>> a
>>>> plain file.
>>>>
>>>>
>>>> The calendar request has:
>>>>
>>>> BEGIN:VCALENDAR
>>>> METHOD:REQUEST
>>>> PRODID:Microsoft Exchange Server 2007
>>>> VERSION:2.0
>>>> BEGIN:VTIMEZONE
>>>> TZID:Pacific Standard Time
>>>> BEGIN:STANDARD
>>>> DTSTART:16010101T020000
>>>> TZOFFSETFROM:-0700
>>>> TZOFFSETTO:-0800
>>>> RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
>>>> END:STANDARD
>>>> BEGIN:DAYLIGHT
>>>> DTSTART:16010101T020000
>>>> TZOFFSETFROM:-0800
>>>> TZOFFSETTO:-0700
>>>> RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
>>>> END:DAYLIGHT
>>>> END:VTIMEZONE
>>>>
>>>>
>>>>
>>>>
>>>> The .html component has:
>>>>
>>>> <div>When: Wednesday, January 09, 2013 4:00 PM-4:30 PM (UTC-08:00)
>>>> Pacific
>>>> Time(US & Canada).</div>
>>>>
>>>> The plain part that has:
>>>>
>>>> When: Wednesday, January 09, 2013 4:00 PM-4:30 PM (UTC-08:00) Pacific
>>>> Time
>>>> (US & Canada).
>>>>
>>>>
>>>>
>>>> Seems like Kronolith is reading the calendar part of the attachment and
>>>> balks on the the TZID included by Exchange.
>>>
>>>
>>>
>>> I don't have an exchange account to test this, but it appears to be
>>> working for me in Horde4/Imp5 - including sending the reply.
>>
>>
>> Having just received an Exchange invite (with a Western E uropean
>> timezone identifier), I can confirm this works flawlessly in
>> Horde4/Imp5 - the appointment is added to the calendar and the reply
>> is sent.
>>
>> In my Horde5/Imp6 install, I have the error that the it cannot
>> communicate with the server when trying to add the invite to the
>> calendar and additionally that  no From: address is set when trying to
>> notify the sender (whether with or without adding it to the calendar).
>
>
> That is because in Horde 4 we completely ignored the timezone provided in
> the iCal data during import.

Might that be a work-around until we get this fixed?  What unintended
consequences did that have?  I wasn't able to follow entirely the
discussions between you and Michael S, but I did gather the proposed
solution of matching time-zones wasn't scalable (and MS might always
change them again - though it's not likely.  And if they don't someone
else will...).

Simon