(In reply to comment #0)

Okay, perhaps this is not as simple as i stated.

I am perhaps being confused by newly created and *imported*
'std.ics' entries.  and recurrence may be playing a part.

TZ= and reinit ktimezoned actually do not seem to correct
korgac behaviour and 'kquitapp korgac && korgac' may not
as well.

I think this is perhaps an "Import Calendar" failure.  I
imported my 'std.ics' from Debian Lenny (and Sarge and Etch)
into a clean Debian Squeeze install (new .kde subdir).

But, now that i look at that std.ics AND the records for it
in the new 'std.ics' file, i see that an event that has been
causing me grief is marked in Z-time (and it's recurrent)

I enabled all korganizer/korgac debugging in kdebugdialog, and:

sdowdy@zia$ grep korgac .xsession-errors 
...
korgac(15312)/kdecore (K*TimeZone*) KSystemTimeZonesPrivate::readConfig: readConfig(): local zone= "US/Mountain"
korgac(15312)/kdecore (K*TimeZone*) KSystemTimeZonesPrivate::readZoneTab: readZoneTab( "/usr/share/zoneinfo/zone.tab" )
...  (yay, that looks good)
korgac(15312)/kresources KRES::Resource::open: Opening resource "Default Calendar"
korgac(15312)/kdepimlibs (kcal) KCal::ResourceCached::doOpen: Opening resource "Default Calendar"
korgac(15312)/kdepimlibs (kcal) KCal::ICalFormat::load: "/home/sdowdy/.kde/share/apps/korganizer/std.ics"
korgac(15312)/kdepimlibs (kcal) KCal::ICalTimeZoneSource::parse: VTIMEZONE "US/Mountain"
korgac(15312)/kdepimlibs (kcal) KCal::ICalTimeZoneSource::parse: VTIMEZONE "US/Mountain"
...  (that looks good)
korgac(15312) AlarmDialog::addIncidence: adding incidence CRIKEY"                                                                                                          
...
kwin(15244) KWin::Client::readUserTimeMapTimestamp: User timestamp, final: 'ID: 41943048 ;WMCLASS: "korgac" : "korgac" ;Caption: "Reminders ? KOrganizer Reminder Daemon" ' : 628031733

korgac(15312)/kdepimlibs (kcal) KCal::Calendar::appendAlarms: "meeting" ': "2011-06-20T23:00:00Z"
korgac(15312)/kdepimlibs (kcal) KCal::Calendar::appendAlarms: "CRIKEY" ': "2011-06-20T17:00:00-06:00"
korgac(15312)/korgac (check) KOAlarmClient::checkAlarms: REMINDER: "meeting"
korgac(15312) AlarmDialog::addIncidence: adding incidence  "meeting"

--- This newly added record "CRIKEY" has TZID directives in the DT{START,END} bits
BEGIN:VEVENT
DTSTAMP:20110620T224455Z
CREATED:20110620T222329Z
UID:KOrganizer-877547988.372
SEQUENCE:2
LAST-MODIFIED:20110620T224455Z
SUMMARY:CRIKEY
DTSTART;TZID=US/Mountain:20110620T173000
DTEND;TZID=US/Mountain:20110620T193000
TRANSP:OPAQUE
BEGIN:VALARM
DESCRIPTION:
ACTION:DISPLAY
TRIGGER;VALUE=DURATION:-PT30M
END:VALARM
END:VEVENT

This "meeting" event has no TZID, using "Zulu":

BEGIN:VEVENT
DTSTAMP:20110620T224455Z
ORGANIZER;CN="Stephen Dowdy":MAILTO:sdowdy@ucar.edu
CREATED:20110620T224422Z
UID:KOrganizer-1245739618.505
SEQUENCE:1
LAST-MODIFIED:20110620T224422Z
SUMMARY:meeting
DTSTART:20110620T233000Z
DTEND:20110621T003000Z
TRANSP:OPAQUE
BEGIN:VALARM
DESCRIPTION:
ACTION:DISPLAY
TRIGGER;VALUE=DURATION:-PT30M
END:VALARM
END:VEVENT

and it was derived from the following record with a Recurrence Rule (by moving it
in the korganizer "week view" display 2.5 hours later, and using "This Occurrence only")

BEGIN:VEVENT
DTSTAMP:20110620T224455Z
ORGANIZER;CN="Stephen Dowdy":MAILTO:sdowdy@ucar.edu
CREATED:20110215T204651Z
UID:libkcal-1486749757.556
SEQUENCE:1
LAST-MODIFIED:20110620T224422Z
SUMMARY:meeting
RRULE:FREQ=WEEKLY;BYDAY=MO
EXDATE;VALUE=DATE:20110620
DTSTART:20110214T220000Z
DTEND:20110214T230000Z
TRANSP:OPAQUE
BEGIN:VALARM
DESCRIPTION:
ACTION:DISPLAY
TRIGGER;VALUE=DURATION:-PT30M
END:VALARM
END:VEVENT


Grrr, but now i logged out, back in without TZ or reinit KTimezoneDaemon
and korgac is working properly for those two events today.  (it did not
when the RRULE record was left as-is, and triggered for 3PM incorrectly,
instead of 2PM as it should have.

This is frustrating, because previously, it would be one hour late.  (So,
i'm suspecting making that one occurrence change didn't affect DST,
and is why it's working, when the original recurring event didn't
work earlier today).

For the Single "meeting" Occurrence record:
sdowdy@zia$ date -d "2011-06-20 23:30:00 GMT"
Mon Jun 20 17:30:00 MDT 2011

From the Recurring "meeting" record:
sdowdy@zia$ date -d "2011-02-14 22:00:00 GMT"                 
Mon Feb 14 15:00:00 MST 2011

So, it was initially MST, when the event was created in February.

What's interesting in the 'Korganizer' "EDIT EVENT" subwindow, is that
the start/end times are marked "US/Mountain", when the event is stored
in Zulu.   But, certainly 'korganizer' has the event displaying in a
day block at the correct time, so it can certainly figure out the
correct time of the event when korgac can't.

Anyway, i suppose i will have to do a few more tests:

  - Add a NEW recurrent event  coinciding with old Imported recurrent
    events to see if korgac reports either of them correctly.  (and
    if the new event has TZID directives)

to Summarize...

korgac incorrectly displays recurring events that were created using korganizer in KDE3 if the current timezone Daylight Savings Time setting differs from the creation time of the recurring event.

(i.e. if i created a recurrent event during MDT, but it's now MST, the time is an hour off, but if the recurring event was created in MST and it's now MST, the time is correct (same for MDT create, MDT display alarm time)

So, there's certainly the possibility that my 'std.ics' is somehow corrupt, I note that it has two identical "BEGIN:VTIMEZONE..END:VTIMEZONE" sections, e.g.,  but it was only ever constructed/managed using KDE3's 'korganizer', which presents a KDE3->KDE4 transition support issue if i'm not the only one hit by this.

This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present?

If noone confirms this bug for a Framework-based version of korgac (version 5.0 or later, as part of KDE Applications 15.08 or later), it gets closed in about three months.

Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.