Closed Bug 349788 Opened 19 years ago Closed 19 years ago

Recurring events within current timezone offset from midnight do not display

Categories

(Calendar :: Calendar Frontend, defect)

Product:
Calendar
Component:
Calendar Frontend
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
Sunbird 0.3

People

(Reporter: thbodner, Assigned: mattwillis)

References

Details

(Keywords: dataloss)

Attachments

(2 files, 2 obsolete files)

observe correct branch (checked in)
1.42 KB, patch
mattwillis
: first-review+
mvl
: second-review+
Details | Diff | Splinter Review
Forces searchStart to !isDate
1.36 KB, patch
ssitter
: first-review+
dmosedale
: second-review+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6 Recurring events within current timezone offset from midnight do not display in day view Reproducible: Always Steps to Reproduce: 1.Start Sunbird 2.Create Event that is within the amount of your timezone offset from midnight 3.Compare Day View with other views Actual Results: Non-recurring events will show up, and the recurring event will show up in other views. But, it will disappear in day view. Expected Results: Recurring events should not disappear in day view when you are within the amount of your timezone offset from midnight.
This blocks 0.3 if we can get a confirmation. -> qawanted.
Keywords: qawanted
Version: unspecified → Trunk
Confirming using Timezone Africa/Ceuta, Events starting at 01.00
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking0.3+
Keywords: qawanted
(In reply to comment #2) > Confirming using Timezone Africa/Ceuta, Events starting at 01.00 > Confirming on negative offset timezones as well as positive: 1. Set OS Timezone to US/Central (America/Chicago) 2. Start Sunbird 3. Using weekview create event that goes from 22:00 to 23:00 and recurs daily for three days 4. Switch to day view and look at the three days of the event Results: Step 3 --> Event is created in week view and displayed Step 4 --> No event in day view
This probably won't fix the whole bug, but it needs to be done. Without this patch, switching a timezone pref requires the app to be restarted to take effect in the day view.
Attachment #235421 - Flags: second-review?(dmose)
Attachment #235421 - Flags: first-review?(mattwillis)
Comment on attachment 235421 [details] [diff] [review] observe correct branch (checked in) You need to change the branch in the destructor to be "calendar." as well. r1=lilmatt with that fix.
Attachment #235421 - Flags: first-review?(mattwillis) → first-review+
The other views are also affected: the mentioned events are not shown on first day of the week view/first day of month view. Using Thunderbird 1.5.0.5 (20060719) and Lightning 2006083006
Whiteboard: [patch in hand][patch doesn't fix everything][needs dmose review]
Whiteboard: [patch in hand][patch doesn't fix everything][needs dmose review] → [patch in hand][patch doesn't fix everything][needs dmose review][no l10n impact]
Comment on attachment 235421 [details] [diff] [review] observe correct branch (checked in) r2=mvl
Attachment #235421 - Flags: second-review?(dmose) → second-review+
Comment on attachment 235421 [details] [diff] [review] observe correct branch (checked in) Patch (w/ nit) checked in on MOZILLA_1_8_BRANCH and trunk.
Attachment #235421 - Attachment description: observe correct branch → observe correct branch (checked in)
Whiteboard: [patch in hand][patch doesn't fix everything][needs dmose review][no l10n impact] → [no l10n impact]
Using tz America/New_York, I created a new event from 22:00 to 23:00. The following appears in the Error Console: Error: tree.eventView has no properties Source File: chrome://calendar/content/unifinder.js Line: 208
Whiteboard: [no l10n impact] → [no l10n impact][needs patch]
*** Bug 340449 has been marked as a duplicate of this bug. ***
Bug 351996 is a confirmation that this bug occurs in all views. Should this bug only deal with day view or is it o.k. to change summary to reflect that all views are affected?
Component: Internal Components → Calendar Views
QA Contact: base → views
Summary: Day View: Recurring events within current timezone offset from midnight do not display → Recurring events within current timezone offset from midnight do not display
(In reply to comment #11) I'm only seeing this (using Clint's STR) in day view. The event shows in all other views just fine. I'm not convinced that bug is a dupe.
(In reply to comment #12) > (In reply to comment #11) > I'm only seeing this (using Clint's STR) in day view. The event shows in all > other views just fine. I'm not convinced that bug is a dupe I was wrong. This _is_ visible in all views. You just need to have a recurring event that recurs on the last day visible in the view, within the timezone offset. (ex: I had to have a recurring event on Saturday at 10pm America/New_York to see the bug in week view) bug 351996 _is_ a dupe
*** Bug 351996 has been marked as a duplicate of this bug. ***
Attached image js stack of issue (obsolete) —
This patch adds the same convertDate helper function we use in calEvent and calTodo to calRecurrenceInfo, so that we ensure the params are proper datetime objects before sending it into C++. If the params isDate == true, the comparisons get all wacky with respect to timezones, and that is the underlying cause of this bug. If we check this in, we should file a spinoff bug to consolidate the use of convertDate into calUtils or the like, but in the interest of keeping the patch small and as regression-free as possible, we didn't do that here.
Assignee: nobody → mattwillis
Status: NEW → ASSIGNED
Attachment #239561 - Flags: second-review?(dmose)
Attachment #239561 - Flags: first-review?(cmtalbert)
Whiteboard: [no l10n impact][needs patch] → [no l10n impact]
Comment on attachment 239561 [details] [diff] [review] rev0 - ensure params are datetime objects (!isDate) Looks good. Tested it. Fixes the issue.
Attachment #239561 - Flags: first-review?(cmtalbert) → first-review+
btw: Mad props to ctalbert for helping me debug part of this
Comment on attachment 239561 [details] [diff] [review] rev0 - ensure params are datetime objects (!isDate) Nice work! r2=dmose with the spinoff bug filed.
Attachment #239561 - Flags: second-review?(dmose) → second-review+
Whiteboard: [no l10n impact] → [no l10n impact][needs checkin]
Patch checked in on MOZILLA_1_8_BRANCH and trunk. -> FIXED
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
OS: Windows XP → All
Hardware: PC → All
Resolution: --- → FIXED
Whiteboard: [no l10n impact][needs checkin] → [no l10n impact]
(In reply to comment #19) > (From update of attachment 239561 [details] [diff] [review] [edit]) > Nice work! r2=dmose with the spinoff bug filed. Spinoff is bug 353707
VERIFIED with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060922 Calendar/0.3a2+
Status: RESOLVED → VERIFIED
Depends on: 353797
I still see (or see again) this issue using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060923 Calendar/0.3a2+ and storage calendar. My local timezone is UTC+2. If repeating event starts at e.g. 01:00 it's not showing in day view. In all other views this is only seen for the first day in view.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(In reply to comment #23) > I still see (or see again) this issue using Mozilla/5.0 (Windows; U; Windows NT > 5.0; en-US; rv:1.9a1) Gecko/20060923 Calendar/0.3a2+ and storage calendar. The Right Way to fix this is in the C++ (bug 353887). Stefan, Did this work properly after I landed the rev0 patch in this bug, but before I landed the patch in bug 353797? If so, perhaps we can fix this in the JS for 0.3. If not, we should cut our losses with these workarounds and fix it The Right Way in the C++.
No longer blocks: 321653
Severity: normal → major
Depends on: 353887
Whiteboard: [no l10n impact] → [needs input from ssitter]
Target Milestone: --- → Sunbird 0.3
(In reply to comment #24) Yes, this worked after this checkin but came back after bug 353797 checkin. Fails in 2006-09-21-14 build Works in 2006-09-22-01 build Works in 2006-09-22-15 build Fails in 2006-09-23-04 build
(In reply to comment #25) > Yes, this worked after this checkin but came back after bug 353797 checkin. With my timezone set to Europe/Berlin, this appears to fix it for me.
Attachment #239541 - Attachment is obsolete: true
Attachment #239561 - Attachment is obsolete: true
Attachment #239916 - Flags: second-review?(jminta)
Attachment #239916 - Flags: first-review?(ssitter)
Whiteboard: [needs input from ssitter] → [patch in hand][needs review ssitter jminta]
Comment on attachment 239916 [details] [diff] [review] Forces searchStart to !isDate r1=ssitter
Attachment #239916 - Flags: first-review?(ssitter) → first-review+
Whiteboard: [patch in hand][needs review ssitter jminta] → [patch in hand][needs review jminta]
Attachment #239916 - Flags: second-review?(jminta) → second-review?(dmose)
Whiteboard: [patch in hand][needs review jminta] → [patch in hand][needs review dmose]
Comment on attachment 239916 [details] [diff] [review] Forces searchStart to !isDate r=dmose
Attachment #239916 - 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: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → FIXED
Whiteboard: [patch in hand][needs checkin]
*** Bug 354198 has been marked as a duplicate of this bug. ***
Whiteboard: [litmus testcase wanted]
qawanted: without details how time zone works and how can it be checked in Sunbird there is no chance to prepare good test cases
Keywords: qawanted
(In reply to comment #31) > qawanted: without details how time zone works and how can it be checked in > Sunbird there is no chance to prepare good test cases > I'm not exactly sure what you want. There are steps to reproduce this issue in the bug, and you can use those to create a test case from. As far as what is happening here, I will try to explain the principle behind this type of timezone testing. Actually, I started writing an entire essay on it, so I decided to put it on the wiki. Here's the link, if anyone has suggestions of where this might best go, I'm open to them: http://wiki.mozilla.org/User_talk:Ctalbert Hope that helps.
Keywords: qawanted
(In reply to comment #32) > (In reply to comment #31) > > qawanted: without details how time zone works and how can it be checked in > > Sunbird there is no chance to prepare good test cases > > > I'm not exactly sure what you want. Answer for question: what's the point that with timezone we have so many problems. At least basic knowledge how it works. What's happen if... why etc Without this I skip bugs with timezone because I don't feel ready to verify them :) > go, I'm open to them: http://wiki.mozilla.org/User_talk:Ctalbert > Hope that helps. Yes it does, thank you Clint
Verified. Sunbird 2006100207/windows.
Status: RESOLVED → VERIFIED
(In reply to comment #33) > > go, I'm open to them: http://wiki.mozilla.org/User_talk:Ctalbert > > Hope that helps. Resolving bug 296007 will help testers much, really
Flags: in-litmus?
Whiteboard: [litmus testcase wanted]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: