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

[Michael J Rubinsky]

Quoting Michael M Slusarz <slusarz at horde.org>:

> Quoting Oscar del Rio <delrio at mie.utoronto.ca>:
>
>> On 01/ 9/13 04:50 PM, Michael M Slusarz wrote:
>>> 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
>>
>> It seems to be already available, from egroupware.org.  Can it be  
>> used in horde?
>>
>> Found it here:
>> http://svn.stylite.de/egwdoc/nav.html?calendar/setup/tz_aliases.inc.php.source.html
>
> 1) The code is released under GPL.  However, the two most logical  
> places to put something like this (Horde and/or a framework library)  
> are released under LGPL.  So we'd have to do some annoying packaging  
> tricks to work around this.
> 2) It seems to me the proper solution would be to ignore the TZID  
> information when the Icalendar data contains the timezone offsets  
> (as in this case).  But I will defer to our ical experts to comment  
> on this.

This won't work for importing the iCal. Since the RFC does not specify  
that the TZID need to conform to any standard, nor does it state that  
the timezone rules specified need to actually match an existing valid  
OLSEN/TZDB timezone (which is the cause of this problem to begin  
with), we can't simply convert the provided timezone rules/offsets  
into a known TZID - we would have to store the entire VTIMEZONE  
component with the event data then EVERY time we need the event's time  
we would need to use the VTIMEZONE to run an algorithm to determine  
the current time we want. This would be a nightmare. So, option (2) is  
not desirable.

Option (1) would be the least objectionable solution if we can work  
around the license issues.

-- 
mike

The Horde Project (www.horde.org)
mrubinsk at horde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6062 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.horde.org/archives/horde/attachments/20130109/f0467ba4/attachment.bin>