[horde] Can't add Outlook meeting request to Kronolith
Michael J Rubinsky
mrubinsk at horde.org
Wed Jan 9 23:48:41 UTC 2013
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.,
>> It seems to be already available, from egroupware.org. Can it be
>> used in horde?
>> Found it here:
> 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
Option (1) would be the least objectionable solution if we can work
around the license issues.
The Horde Project (www.horde.org)
mrubinsk at horde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6062 bytes
Desc: S/MIME Cryptographic Signature
More information about the horde