Closed
Bug 339509
Opened 18 years ago
Closed 18 years ago
Wrong day highlighted after click in minimonth when using Day view
Categories
(Calendar :: Sunbird Only, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: ssitter, Assigned: thomas.benisch)
Details
Attachments
(3 files)
1.86 KB,
patch
|
jminta
:
first-review+
|
Details | Diff | Splinter Review |
1.13 KB,
patch
|
jminta
:
first-review+
|
Details | Diff | Splinter Review |
1.20 KB,
patch
|
jminta
:
first-review+
|
Details | Diff | Splinter Review |
Wrong day highlighted after click in minimonth when using Day view Steps to Reproduce: 1. Switch to Day view 2. Click on a day (e.g. 5/28) in minimonth to select this date in Day view. Actual Results: The correct day (5/28) is shown in Day view but 5/27 is highlighted in minimonth. Expected Results: The correct day is highlighted in minimonth. Additional Information: Problem only happens if the local timezone is GMT+x. (GMT+2 in my case). Problem does not happen if Week/Multiweek/Month view is displayed. After click into Day view the correct day is highlighted in minimonth. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060527 Mozilla Sunbird/0.3a2+
Comment 1•18 years ago
|
||
Is this a regression? I thought I've fixed this bug before.
Reporter | ||
Comment 2•18 years ago
|
||
(In reply to comment #1) Yeah, looks like a regression, most probably due to Bug 329225. Works in 2006-05-18 build Fails in 2006-05-19 build
Assignee | ||
Comment 3•18 years ago
|
||
I think we have a general timezone problem here. The minimonth uses a JavaScript Date object with the timezone always set to the local timezone (system timezone). In the views the timezone can be set by the user. If both timezones differ, there a conversion problems. In Lightning there's a similar timezone problem, if the timezone offset of the view is less than the local timezone offset (e.g. view: America/Toronto, system: Europe/Berlin). When clicking on a date in the minimonth, the highlighted date in the view (month/week/day) and the highlighted date in the minimonth is one day less than the original selected date. In principal I see two possibilities: 1.) add a timezone to the minimonth, so that the minimonth uses the same timezone as the views 2.) stay with the JavaScript date object in the minimonth and fix the problem in all date conversions I think 1.) is difficult, especially as the minimonth is supposed to move to the toolkit. Therefore one cannot use calIDateTime. As the code for the date conversion is different for Lightning and SunBird, the Lightning case can be also handled in a separate task. Although this looks like a regression introduced with #329225, I think there must have been some timezone problems already before, but probably I'm wrong.
Reporter | ||
Comment 4•18 years ago
|
||
(In reply to comment #3) > I think we have a general timezone problem here. I don't think so. As written in bug description: It works if the Week/Multiweek/Month view is displayed. It only fails if the Day view is displayed. I have not looked as the source code until now so I can't say what caused this.
Assignee | ||
Comment 5•18 years ago
|
||
This patch handles the Lightning code only.
Attachment #223693 -
Flags: first-review?(jminta)
Reporter | ||
Comment 6•18 years ago
|
||
Ok, I just checked with Lightning 0.1+ (20060528) and Thunderbird 0.3a1 (20060526) and the problem does not occurred. So this seems to be a Sunbird only problem.
Assignee | ||
Comment 7•18 years ago
|
||
(In reply to comment #3) > In Lightning there's a similar timezone problem, if the > timezone offset of the view is less than the local timezone > offset (e.g. view: America/Toronto, system: Europe/Berlin). > When clicking on a date in the minimonth, the highlighted date > in the view (month/week/day) and the highlighted date in the > minimonth is one day less than the original selected date. I just checked, that this problem also shows up in SunBird.
Assignee | ||
Comment 8•18 years ago
|
||
This patch fixes the day view specific problem for SunBird.
Assignee: nobody → thomas.benisch
Status: NEW → ASSIGNED
Attachment #223904 -
Flags: first-review?(jminta)
Assignee | ||
Comment 9•18 years ago
|
||
This patch fixes the problem described in comment #3 for SunBird.
Attachment #223905 -
Flags: first-review?(jminta)
Comment 10•18 years ago
|
||
Comment on attachment 223904 [details] [diff] [review] patch2 (day view problem, SunBird only) r=jminta
Attachment #223904 -
Flags: first-review?(jminta) → first-review+
Updated•18 years ago
|
Attachment #223905 -
Flags: first-review?(jminta) → first-review+
Updated•18 years ago
|
Attachment #223693 -
Flags: first-review?(jminta) → first-review+
Comment 11•18 years ago
|
||
All patches checked in. Thanks for the work on this!
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Comment 12•18 years ago
|
||
not able to give you scenario but problem still occurs - I checked time zone - selected day in unfinder has changed but in main view not Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060824 Calendar/0.3a2+
Reporter | ||
Comment 13•18 years ago
|
||
The issue I reported is fixed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060824 Calendar/0.3a2+. The correct day is highlighted in minimonth. --> VERIFIED (In reply to comment #12) Damian, you issue doesn't match the issue reported in this bug at all. Please file a new one if you can reproduce the issue.
Status: RESOLVED → VERIFIED
Updated•17 years ago
|
Whiteboard: [litmus testcase wanted]
Comment 14•17 years ago
|
||
Litmus testcase 2605 created
Comment 15•17 years ago
|
||
Litmus testcase 2624 created
Updated•17 years ago
|
Whiteboard: [litmus testcase wanted]
You need to log in
before you can comment on or make changes to this bug.
Description
•