9:36 p.m.
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> 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.