Closed Bug 351737 Opened 13 years ago Closed 13 years ago

repeat until date on events becomes the next day

Categories

(Calendar :: General, defect)

defect
Not set

Tracking

(Not tracked)

VERIFIED FIXED
Sunbird 0.3

People

(Reporter: bugzilla, Assigned: mattwillis)

References

Details

(Keywords: dataloss)

Attachments

(1 file, 1 obsolete file)

User-Agent:       Opera/9.01 (Windows NT 5.2; U; en)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9a1) Gecko/20060906 Calendar/0.3a2+

when i set an event to repeat until a certain date, looking at the repeat settings of that event later show it to repeat until the day after i set. the calendar is not updated to include the event on that day, however, unless you click ok in the edit recurrence and edit event dialog boxes.

Reproducible: Always

Steps to Reproduce:
1. create an event that repeats until a certain date.
2. close and reopen sunbird.
3. edit all occurrences of the event.
4. click "set pattern" to view the recurrence options.

Actual Results:  
the repeat until date is the day after it was set to.

Expected Results:  
the repeat until date should not change.

this might be a time zone problem. my offset is -1000 (pacific/honolulu). i exported the calendar containing the event as an ical file and looked at it in a text editor. the event, which was set to repeat until 2006-09-08 (sep. 8), contained the line "RRULE:FREQ=DAILY;UNTIL=20060909T095959;INTERVAL=1". note that that's 2006-09-08 12:59:59 local time converted to gmt. i changed the time zone in sunbird to +0700 (asia/bangkok), left my operating system time zone at -1000, and repeated the test. the exported ical file had an RRULE:FREQ line identical to the above.
duplicate of bug 330943?

I can confirm that the UNTIL time is converted to UTC based on the operating system timezone, not based on the timezone set in options.
*** Bug 330943 has been marked as a duplicate of this bug. ***
Following the steps given, I can confirm this issue.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking0.3+
Keywords: dataloss
(In reply to comment #0)
> this might be a time zone problem. my offset is -1000 (pacific/honolulu). i
> exported the calendar containing the event as an ical file and looked at it in
> a text editor. the event, which was set to repeat until 2006-09-08 (sep. 8),
> contained the line "RRULE:FREQ=DAILY;UNTIL=20060909T095959;INTERVAL=1". note
> that that's 2006-09-08 12:59:59 local time converted to gmt.

Yes. From RFC2445 4.3.10:
   "The UNTIL rule part defines a date-time value which bounds the
   recurrence rule in an inclusive manner. If the value specified by
   UNTIL is synchronized with the specified recurrence, this date or
   date-time becomes the last instance of the recurrence. If specified
   as a date-time value, then it MUST be specified in an UTC time
   format. If not present, and the COUNT rule part is also not present,
   the RRULE is considered to repeat forever."

It _should_ be in UTC, and since it's inclusive, we set it to one millisecond before midnight of the NEXT morning.

This looks to be jsDate crap on the loadDialog() of the recurrence dialog
Status: NEW → ASSIGNED
Attached patch swaps jsDate for getInTimezone (obsolete) — Splinter Review
Assignee: nobody → mattwillis
Attachment #238682 - Flags: second-review?(dmose)
Attachment #238682 - Flags: first-review?(ssitter)
OS: Windows Server 2003 → All
Hardware: PC → All
Whiteboard: [patch in hand][needs review ssitter dmose]
Target Milestone: --- → Sunbird 0.3
This patch converts a floating rule.endDate to UTC so that endDate.getInTimezone() works properly.
Attachment #238682 - Attachment is obsolete: true
Attachment #239233 - Flags: second-review?(dmose)
Attachment #239233 - Flags: first-review?(cmtalbert)
Attachment #238682 - Flags: second-review?(dmose)
Attachment #238682 - Flags: first-review?(ssitter)
Whiteboard: [patch in hand][needs review ssitter dmose] → [patch in hand][needs review ctalbert dmose]
Comment on attachment 239233 [details] [diff] [review]
rev1 - forces rule.endDate to UTC

R1+ With the removal of the two semicolons at the end of the getInTimezone("UTC") line. Tested the fix. It works.
Attachment #239233 - Flags: first-review?(cmtalbert) → first-review+
Whiteboard: [patch in hand][needs review ctalbert dmose] → [patch in hand][needs review dmose]
Comment on attachment 239233 [details] [diff] [review]
rev1 - forces rule.endDate to UTC

Looks good; r2=dmose.
Attachment #239233 - Flags: second-review?(dmose) → second-review+
Whiteboard: [patch in hand][needs review dmose] → [patch in hand][needs checkin]
Patch checked in on MOZILLA_1_8_BRANCH and trunk.

-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [patch in hand][needs checkin]
Depends on: 353725
verified with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060929 Sunbird/0.3
Status: RESOLVED → VERIFIED
Whiteboard: [litmus testcase wanted]
Litmus testcase 2690 created
Whiteboard: [litmus testcase wanted]
You need to log in before you can comment on or make changes to this bug.