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

[Jan Schneider]

Zitat von Michael J Rubinsky <mrubinsk at horde.org>:

> Quoting Michael M Slusarz <slusarz at horde.org>:
>
>> Quoting Michael J Rubinsky <mrubinsk at horde.org>:
>>
>>> Quoting Michael M Slusarz <slusarz at horde.org>:
>>>
>>>> 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.
>>>
>>
>> [snip]
>>
>>> 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.
>>
>> Option (1) is even more worthless though, since TZID can be ANY  
>> string - there is no guarantee the text corresponds to any known  
>> timezone identifier.  So trying to do a Timezone -> TZDB  
>> translation *solely* on the TZID string is absolutely NOT the  
>> correct solution.  At best, it is a terrible lazy hack.
>>
>> It may be a "nightmare", but the only 2 viable and correct options  
>> appear to be:
>>
>> 1) Storing the timezone information with the event.
>
> Not acceptable. See previous reply.
>
>> 2) Mapping a timezone string -> Olsen/TZDB string based on the  
>> timezone offsets contained within the VTIMEZONE.
>
> This is doable, but not foolproof. It's similar to what I do in  
> ActiveSync's timezone support. I would suggest a combination of the  
> two:
>
> Create a mapping as described in (1). Attempt to sniff out the  
> correct timezone based on offsets/transitions using the mapped OLSEN  
> name as a preferred result in the case of non-unique results. See  
> Horde_ActiveSync_Timezone for more information.

This is probably not more reliable than using the static map from  
unicode.org. It's so simple that we don't need any external code. I  
haven't looked at the egroupware code yet, so I could do a blind  
development.

The problem with the matching-approach is, that you could even make up  
your own timezones (see bug ticket), or only specify rules for a  
certain period of time, which makes matching so unreliable.
-- 
Jan Schneider
The Horde Project
http://www.horde.org/