
This patch adds proper timezone handling to the Horde framework so  
that icalendar invitations / events sent from users in other timezones  
are viewed and imported properly. Prior to this patch, when importing  
a calendar event into Kronolith (or viewing it in IMP) from a user in  
a different timezone Horde would not respect the timezone specified  
for the event and erroneously import or show the event as if it were  
scheduled for local time. Actually, if the sending application  
specified the date / time as UTC (as Horde Kronolith does itself) then  
this does not apply and Horde handled it properly. However most  
applications do not specify events in that way and Horde did not  
handle them properly. This patch fixes that. The most notable  
application that did not work properly with Horde is of course  
Microsoft Outlook / Exchange.

For example, I work near San Francisco (US/Pacific timezone) but my  
employer is based in Atlanta (US/Eastern timezone). Previously if a  
coworker based in Atlanta sent me a calendar invite for a conference  
call that began at 9am Eastern time Kronolith would import and show it  
as being 9am Pacific time which would make me 3 hours late for the  
call if I relied on it. After the patch, Horde properly realizes that  
9am Eastern is 6am Pacific and imports / shows the event at that time.

I did this patch the right way and the code conforms to the iCalendar  
specification (RFC2445). I have extensively tested it and I am  
satisfied that it interoperates correctly with all RFC conforming  
calendar applications including Microsoft Outlook / Exchange, Apple  
iCal, Mozilla Calendar and others. Further, the changes are all in one  
file and internal to the iCalendar object in the Horde framework so  
there are no changes that are necessary to the applications  
(Kronolith, IMP, etc.) Therefore, I believe this patch is ready for  
immediate integration into Horde CVS.

The only externally visible change made (besides correct date /  
times!) is what gets stored in the calendar object when an invalid  
date-time stamp is encountered. Previously, it was not consistent but  
usually false would be stored. After this patch the original text from  
the invitation is stored so that it's not lost.

After applying this patch you will need to run

   framework/install-packages.php -p iCalendar

from the command line as root for it to take affect.

No, it isn't as easy as I am making it sound and it took a while to  
get the patch right! If anyone wishes to discuss the technical aspects  
further please read RFC2445 and send me an email.

One final caveat: because of the way the standard works the sending  
application specifies the exact times of the timezone's changes  
between daylight and standard time (if any). This means that if the  
powers that be change the dates for those changes and the sending  
application does not know about the new rules at the time the  
invitation is sent then there is potential for the receiving  
application (including this code) calculating the incorrect time. That  
is not a bug in the code but an invitation with a timezone component  
specified that is not correct. The sender will need to send an updated  
invitation after updating his computer / software to know about the  
new timezone rules or the recipient will need to manually change the  
time of the event.

I bring this up of course because the US congress has changed when we  
in the US observe our time changes starting in 2007. If the sending  
application / computer of an invite does not know that and it encodes  
incorrect old information about its timezone but the recipient's  
application / computer knows about the new changes and the invitation  
falls on a date between when the sending application thought the time  
change would occur and when the receiving application knows that it  
actually will occur then the time derrived from the invitation will be  
off. Is that confusing enough?

To put it simply, if you notice that some invitations sent by people  
in US timezones for events between March 11, 2007 and April 1, 2007  
appear to be showing up witch a time that is incorrect by exactly one  
hour, it's not a bug in my code but a problem on the sender's end!

Thank you,
Carl E. Thompson


