http://bugs.meego.com/show_bug.cgi?id=8895 Summary: KCalExtended backend: time zone not copied Classification: MeeGo Projects Product: SyncEvolution Version: unspecified Platform: All Architecture: --- Status: NEW Severity: major Priority: High Component: SyncEvolution AssignedTo: patrick.ohly(a)intel.com ReportedBy: patrick.ohly(a)intel.com QAContact: jingke.zhang(a)intel.com CC: patrick.ohly(a)intel.com, syncevolution-bugs(a)meego.bugs, syncevolution-default-bugs(a)meego.bugs Depends on: 6054,8604 Estimated Hours: 0.0 See bug #6049 for an introduction to the test and the full output. BEGIN:VCALENDAR BEGIN:VCALENDAR VERSION:2.0 VERSION:2.0 BEGIN:VEVENT BEGIN:VEVENT SUMMARY:phone meeting SUMMARY:phone meeting CATEGORIES:MEETING CATEGORIES:MEETING CLASS:PUBLIC < DESCRIPTION:let's talk DESCRIPTION:let's talk DTEND;TZID=Europe/Berlin:20060406T1 | DTEND:20060406T143000Z 63000 | DTSTART:20060406T140000Z DTSTART;TZID=Europe/Berlin:20060406 < T160000 < LOCATION:my office LOCATION:my office END:VEVENT END:VEVENT BEGIN:VTIMEZONE < TZID:Europe/Berlin [...] < END:VTIMEZONE < END:VCALENDAR END:VCALENDAR synccompare has simplified the original VTIMEZONE definition here. EXPECTED BEHAVIOR ================= The exported VEVENT should be defined in the original timezone. It might not make a difference for past events, but it is still a loss of information (where was the event defined originally?) and can be wrong for events in the future. It is definitely wrong for recurring events; not sure whether the same transformation would be done also if a RECURRENCE rule had been defined. For a full discussion of why storing events in UTC is not sufficient, see my blog post: http://www.estamos.de/blog/2008/06/30/calendar-time-stamps-and-time-zones/ USER IMPACT =========== Loss of information, possibly incorrect displaying of events. --- Comment #1 from pohly <patrick.ohly(a)intel.com&gt; 2010-10-25 03:36:01 PDT --- +++ This bug was initially created as a clone of Bug #6054 +++ BEGIN:VCALENDAR BEGIN:VCALENDAR VERSION:2.0 VERSION:2.0 BEGIN:VEVENT BEGIN:VEVENT SUMMARY:phone meeting SUMMARY:phone meeting CATEGORIES:MEETING CATEGORIES:MEETING CLASS:PUBLIC < DESCRIPTION:let's talk DESCRIPTION:let's talk DTEND;TZID=Europe/Berlin:20060406T1 | DTEND:20060406T143000Z 63000 | DTSTART:20060406T140000Z DTSTART;TZID=Europe/Berlin:20060406 < T160000 < LOCATION:my office LOCATION:my office END:VEVENT END:VEVENT BEGIN:VTIMEZONE < TZID:Europe/Berlin [...] < END:VTIMEZONE < END:VCALENDAR END:VCALENDAR The time zone information is lost because moving an incidence from in-memory calendar into the system calendar does not copy the time zone definition (bug #6054 comment #9). Moving time zone definitions from one calendar into another is non-trivial because of TZID collisions. There should be an utility function for this in mKCal (bug #8604). In the meantime SyncEvolution should at least move the time zones without checking for collisions). -- Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching someone on the CC list of the bug.