Closed Bug 372366 Opened 17 years ago Closed 17 years ago

After database schema upgrade 6 -> 7 all events are floating, timezone is lost

Categories

(Calendar :: Provider: Local Storage, defect, P1)

Product:
Calendar
Component:
Provider: Local Storage
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
Sunbird 0.5

People

(Reporter: ssitter, Assigned: mattwillis)

References

Details

(Keywords: dataloss, regression)

Attachments

(1 file)

Fixes comparison
1.33 KB, patch
mvl
: first-review+
Details | Diff | Splinter Review 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3pre) Gecko/20070301 Calendar/0.5pre

After switching from Sunbird/0.5pre (2007022804) to Sunbird/0.5pre (2007030104) all events are shifted by -x hours, with x being the UTC offset of your timezone. During that switch the database schema upgrade 6 -> 7 took place.

Exporting the storage calendar to ics shows the problem: 
All tz information is lost, events are converted to UTC and marked floating.

Event created and exported in Sunbird/0.5pre (2007022804):

BEGIN:VEVENT
CREATED:20070302T103132Z
LAST-MODIFIED:20070302T103132Z
DTSTAMP:20070302T103132Z
UID:b4268a32-0601-493c-9fde-0edfddb2e816
SUMMARY:2 Mar 1000-1200
DTSTART;TZID=/mozilla.org/20070129_1/Europe/Berlin:20070302T100000
DTEND;TZID=/mozilla.org/20070129_1/Europe/Berlin:20070302T120000
END:VEVENT
BEGIN:VEVENT

BEGIN:VEVENT
CREATED:20070302T103132Z
LAST-MODIFIED:20070302T103132Z
DTSTAMP:20070302T103132Z
UID:d65546eb-cbb6-4a45-9bff-dba5660dbf64
SUMMARY:28 Feb all day
DTSTART;VALUE=DATE;TZID=/mozilla.org/20070129_1/Europe/Berlin:20070228
DTEND;VALUE=DATE;TZID=/mozilla.org/20070129_1/Europe/Berlin:20070301
END:VEVENT


Event exported in Sunbird/0.5pre (2007030104):

BEGIN:VEVENT
CREATED:20070302T103253Z
LAST-MODIFIED:20070302T103253Z
DTSTAMP:20070302T103253Z
UID:b4268a32-0601-493c-9fde-0edfddb2e816
SUMMARY:2 Mar 1000-1200
DTSTART:20070302T090000
DTEND:20070302T110000
END:VEVENT

BEGIN:VEVENT
CREATED:20070302T103253Z
LAST-MODIFIED:20070302T103253Z
DTSTAMP:20070302T103253Z
UID:d65546eb-cbb6-4a45-9bff-dba5660dbf64
SUMMARY:28 Feb all day
DTSTART;VALUE=DATE:20070227
DTEND;VALUE=DATE:20070228
END:VEVENT
Taking this
Assignee: nobody → lilmatt
Keywords: dataloss
Status: NEW → ASSIGNED
Attached patch Fixes comparison — — Splinter Review 
The code made the erroneous assumption that calICSService::GetLatestTzId would always return the latestTzId, even if the one it was passed in WAS the latest.  Instead in that case it returns nothing.

This fixes the assumption to reflect reality.
Attachment #257025 - Flags: second-review?(mvl)
Attachment #257025 - Flags: first-review?(ctalbert.moz)
Flags: blocking-calendar0.5+
OS: Windows XP → All
Priority: -- → P1
Hardware: PC → All
Target Milestone: --- → Sunbird 0.5
Comment on attachment 257025 [details] [diff] [review]
Fixes comparison

r=mvl
Attachment #257025 - Flags: second-review?(mvl)
Attachment #257025 - Flags: first-review?(ctalbert.moz)
Attachment #257025 - Flags: first-review+
Patch checked in on MOZILLA_1_8_BRANCH and trunk.

-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Verified using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.3pre) Gecko/20070304 Calendar/0.5pre
Status: RESOLVED → VERIFIED
I ran into this problem, and I too can verify that it's now fixed in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3pre) Gecko/20070305 Calendar/0.5pre
Flags: blocking-calendar0.5+
You need to log in before you can comment on or make changes to this bug.