Closed Bug 485570 Opened 11 years ago Closed 11 years ago

absolute alarm with fixed date/time is reset to relative alarm after application restart

Categories

(Calendar :: Provider: Local Storage, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: ssitter, Assigned: Fallen)

References

Details

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090327 Calendar/1.0pre

Steps to Reproduce:
1. Start Sunbird with clean profile
2. Start creating a new event, e.g. 01-Apr-2009 10:00-12:00.
3. Add a custom with fixed date/time, e.g. 31-Mar-2009 16:00
4. Save the event
5. Restart application
6. Open the event, check alarm settings, change title save.

Actual Results:
A custom alarm '18 hours after the events starts' is shown. Event can be saved.

Expected Results:
A custom alarm with fixed date/time as created is shown.

Additional Information:

storage provider event after creation (as copied to clipboard):
    BEGIN:VALARM
    ACTION:DISPLAY
    TRIGGER;VALUE=DATE-TIME:20090331T140000Z
    DESCRIPTION:Default Mozilla Description
    END:VALARM

storage provider event after application restart (as copied to clipboard):
    BEGIN:VALARM
    ACTION:DISPLAY
    TRIGGER;VALUE=DURATION:PT18H
    DESCRIPTION:Default Mozilla Description
    END:VALARM

Probably depends on the waiting storage provider changes in Bug 353492. Either the issue should be fixed for the absolute alarm feature should be disabled.
Flags: blocking-calendar1.0?
Version: unspecified → Trunk
Fails in Sunbird 1.0pre (BuildID: 20090402125816)
Works in Sunbird 1.0pre (BuildID: 20090402141537)

--> FIXED by checkin from Bug 353492 Comment #93.
Assignee: nobody → philipp
Status: NEW → RESOLVED
Closed: 11 years ago
Depends on: 353492
Flags: blocking-calendar1.0?
Resolution: --- → FIXED
Target Milestone: --- → 1.0
Verified fixed using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090611 Calendar/1.0pre (BuildID: 20090611031611)
Status: RESOLVED → VERIFIED
These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".
Target Milestone: 1.0 → 1.0b1
You need to log in before you can comment on or make changes to this bug.