[horde] Can't add Outlook meeting request to Kronolith
jan at horde.org
Thu Jan 10 10:20:35 UTC 2013
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.
>>> 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
> 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
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.
The Horde Project
More information about the horde