Version: 3.5.9 (using 3.5.9, Kubuntu (hardy) 4:3.5.9-0ubuntu7.1) Compiler: Target: x86_64-linux-gnu OS: Linux (x86_64) release 2.6.27-rc4 When I import a calendar in a remote location, the timezones differences aren't reflected in the scheduling. So an invite for 10 AM EST is shown as 10 AM my time (IST).
This is a problem in kubuntu 64-bit intrepid, enough to render the calendar portion of korganizer unusable :-( Running KDE 4.1.3, korganizer 4.1.0. Here is one example: 1. I have my timezone correctly set to America/Denver in korganizer. 2. I am accessing a calendar via webdav; it contains the following event: ---- BEGIN:VEVENT DTSTAMP:20081113T173026Z ORGANIZER;CN=D. R. Evans:MAILTO:N7DR@arrl.net ATTENDEE;CN=D. R. Evans;RSVP=FALSE;PARTSTAT=ACCEPTED;ROLE=REQ-PARTICIPANT: mailto:N7DR@arrl.net CREATED:20081106T230002Z UID:libkcal-309613194.628 SEQUENCE:2 LAST-MODIFIED:20081111T160428Z SUMMARY:Lunch with Rob and Colleen LOCATION:Niwot somewhere CATEGORIES:Appointment DTSTART:20081112T180000Z DTEND:20081112T200000Z TRANSP:OPAQUE BEGIN:VALARM DESCRIPTION: ACTION:DISPLAY TRIGGER;VALUE=DURATION:-PT30M END:VALARM END:VEVENT ---- Note the DTSTART line in particular: DTSTART:20081112T180000Z So the appointment starts at 18:00 UTC. But in korganizer 4.1.0 it appears as starting at 18:00 *local* (i.e., Denver) time, which is obviously wrong. I don't quite understand how such a huge problem made it into released code, but in any case it certainly looks like a big fat bug.
I've experimented a bit more with this, and the problem seems to be limited to the monthly and summary views. In other words, viewing an event in (for example) the weekly view will show the event to have the correct local. Switching to the monthly view, however, will cause the time to be displayed incorrectly.
This is a problem in KDE 4.3 that was NOT present in KDE 4.2.X. Bug 68345 may be related. Fedora Core 11, KDE 4.3 Steps: 1. Open an .ics file from a client like Outlook that was sent from a different time zone. 2. Choose Merge into an Existing Calendar, then Akonadi resource 3. The meeting shows up in the time zone from which it was sent, not my time zone. So, for example, if the meeting originator is on the Pacific coast and the meeting starts at 0800 Pacific Coast Time (US), it should start at 1100 on the East Coast (my time). 4. Open the meeting in Korganizer. Note that the time zone for the meeting is North America / New York. If choosing a non Akonadi resource: 1. Open .ics file as before 2. Choose a non-Akonadi resource for merging the calendar 3. The meeting notice shows up in the correct time, e.g., at 1100 on the East Coast given a start time of 0800 Pacific. 4. Open the meeting notice. Note that the time zone is given as Floating. 5. Make any type of change (or even no change at all) and hit Apply or OK. 6. The meeting notice disappears. 7. Un-check, then re-check the resource where the meeting notice was stored using the Calendar window in the left pane of Korganizer 8. The meeting re-appears, but now at the wrong time, 0800 instead of 1100. 9. Open meeting notice. Time zone remains Floating.
The meeting notices used in the previous post come from Outlook. I setup a Thunderbird calendar on my computer to be in a different time zone (Pacific) than my Korganizer calendar (Eastern). Meeting notices generated by Thunderbird were properly accepted and stored by Korganizer with the appropriate time shift. So, it appears that the "time zone" problem may be limited to Outlook-type meeting notices.
With the recent update to 4.7.0 and the drop of the non-akonadi local ics file calendar, I see this thing with my original ICS file containing the entire calendar. The time zone of non-local appointments is ignored, manually setting to proper zone doesn't move the date.
Or importing ICS files, such as the attached one...
Created attachment 63680 [details] Breaking invitation with contained time zone.
There seems to be a regression in recent versions of PIM. Since the same regression is reported in bug 68345, I'm marking this one as a duplicate of it and will pick up from the information there. Thanks for reporting this! *** This bug has been marked as a duplicate of bug 68345 ***
Hi Stephan, Just to validate, the attached event starts at 11:30 am UTC on Sept 16, right? Thanks again for providing information.
(In reply to comment #9) > Just to validate, the attached event starts at 11:30 am UTC on Sept 16, right? Indeed.