[horde] Can't add Outlook meeting request to Kronolith
Michael J Rubinsky
mrubinsk at horde.org
Thu Jan 10 00:27:44 UTC 2013
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.
>>> 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.
> Nevermind - I was reading the data/spec wrong. There should be
> absolutely no reason we are parsing the timezone string in this case
> via PHP's DateTime since the timezone identification is explicitly
> defined elsewhere in the data (VTIMEZONE block).
This is exactly why we DO use the timezone string when importing into
Kronolith. There is no other sane way to do it. If we simply use the
offsets/transitions from the VTIMEZONE definition, we would have to
store the entire VTIMEZONE component with each event we import and
EVERY time we need to access that event, we must turn that into an
executable algorithm and calculate the times. The would be a
performance nightmare and completely defeats the purpose of using
PHP's DateTime functionality.
> So it looks like the Icalendar parser is not correctly parsing the
> VTIMEZONE block and using this defined timezone later in the VEVENT
> data (e.g. DTSTART/DTEND). This indeed looks like a bug.
We don't parse the VTIMEZONE transitions/offsets at all during import.
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