Changes have been made in Git (develop):

commit 4587a930309b6280703dcc112bde9b700e49aea4
Author: Michael J Rubinsky <mrubinsk@horde.org>
Date:   Sun Sep 30 20:12:09 2012 -0400

     Output iCal in local tz if we have a recurtype that needs a BYDAY.

     Fixes Bug: 11339

  kronolith/lib/Event.php |   15 +++++++++++++++
  1 files changed, 15 insertions(+), 0 deletions(-)

http://git.horde.org/horde-git/-/commit/4587a930309b6280703dcc112bde9b700e49aea4

Fixed for Kronolith 4.0

Changes have been made in Git (master):

commit 4587a930309b6280703dcc112bde9b700e49aea4
Author: Michael J Rubinsky <mrubinsk@horde.org>
Date:   Sun Sep 30 20:12:09 2012 -0400

     Output iCal in local tz if we have a recurtype that needs a BYDAY.

     Fixes Bug: 11339

  kronolith/lib/Event.php |   15 +++++++++++++++
  1 files changed, 15 insertions(+), 0 deletions(-)

http://git.horde.org/horde-git/-/commit/4587a930309b6280703dcc112bde9b700e49aea4

Confirmed. As far as I can tell, the only way to correctly fix this is 
to export the the date-time data in the event's original timezone.

Which means it can't be fixed in Kronolith 3 since proper timezone 
support for iCalendar wasn't added until Horde 5.

When scheduling a repeating meeting whose date in the origin timezone 
is different than the day in the UTC timezone, the resulting iCal file 
has the scheduled times set to UTC time and date, but the "BYDAY" 
repeating setting is not also adjusted for UTC time.

For example, if I create a repeating meeting starting on Monday Aug 
13, 2012, at 23:00 (11pm) EDT (which is UTC-4) every Monday (again, 
Monday in EDT timezone), then the resulting iCal file contains:

DTSTART:20120814T030000Z

which is correct, in UTC time the meeting starts Tuesday Aug 14, 2012, 
at 03:00 UTC.  However, in the repeating meeting section, it 
incorrectly lists the repeating day as Monday:

RRULE:FREQ=WEEKLY;INTERVAL=2;BYDAY=MO;UNTIL=20130101T045959Z

Since the meeting time is listed in UTC, that repeating day must also 
be listed in UTC, which in this case is Tuesday, not Monday.

The result of this bug is that any calendar that uses the BYDAY field 
will schedule all the repeating meetings on the day before they 
actually should occur; in the above example, the Monday night meetings 
would be shown as Sunday night meetings, on any calendar application 
that uses the BYDAY field.

This can be worked around by selecting the "Repeat On" day as one day 
ahead of the actual day; in the above example where meetings repeat 
every Monday at 23:00 EDT, the "Repeat On" day in the Kronolith 
meeting invite interface needs to be selected as "Tuesday" in order 
for other calendar applications to process it as a Monday at 23:00 EDT 
repeating meeting.

To fix this, the BYDAY needs to be adjusted to UTC instead of 
remaining the day in the origin timezone.