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

[Michael J Rubinsky]

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.  
See above.


-- 
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/6285ed9a/attachment-0001.bin>