The test could be better, but this is merged now. Thanks!

Your changes to the patch seem fine and it works fine for me. When 
testing I used several .ics files I found using Google. Some are a bit 
strange but they encompass the range of what's out there. I have 
attached them.

I've committed a slightly modified version of your patch to HEAD 
(syntax tweaks and I moved the parseTZChild() function into the 
vTimezone class). Please check out the changes in HEAD and test 
(anyone, not just Carl), and Carl, if you could submit a test file 
that checks the timezone handling that would be _very_ helpful.



If we have a test for this and it works well in HEAD I'll merge it to 
Horde 3.1.x.



Thanks!

New patch:

- Doesn't use str_ireplace()

- Conform to Horde coding standards

- Doesn't use scary strtotime() voodoo



Chuck wrote:
So that the letter 'n' is matched whether it is capital or lowercase. 
It is looking for the actual string backslash-N.

Your patch uses str_ireplace, a PHP 5-only function. The iCalendar 
component (and nearly all of Horde for the moment) should work with 
PHP 4.3+. Please also read horde/docs/CODING_STANDARDS for a bunch of 
style/indent consistency issues, and upload a fixed patch.



(At least a few places I see why the str_ireplace, but why did you use 
ireplace on array('\\n', '\\;', '\\:') ?)

Attached is a patch (against HEAD - 1 Sep 2006) that adds proper 
timezone handling to the Horde framework so that icalendar invitations 
/ events sent from users in other timezones are viewed and imported 
properly.



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.



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 at the sender's end! Any 
software that imports calendar events using the standard may have this 
problem.



Thank you,

Carl E. Thompson

Are you going to upload your patch, too?

To be clear this is a problem with the iCalendar module in the Horde 
framework not in Kronolith.

When importing a calendar event into Kronolith (or viewing it in IMP) 
from a user in a different timezone Horde does not respect the 
timezone specified for the event and erroneously imports or shows the 
event as if it were scheduled for local time. Actually, if the sending 
application specifies the date / time as UTC (as Horde Kronolith does 
itself) then this does not apply and Horde handles it properly. 
However most applications do not specify events in that way and Horde 
does not handle them properly. The most notable application that does 
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). If a coworker 
based in Atlanta sends me a calendar invite for a conference call that 
began at 9am Eastern time Kronolith will import and show it as being 
9am Pacific time which would make me 3 hours late for the call if I 
rely on it.