Closed Bug 339509 Opened 17 years ago Closed 17 years ago

Wrong day highlighted after click in minimonth when using Day view

Categories

(Calendar :: Sunbird Only, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: ssitter, Assigned: thomas.benisch)

Details

Attachments

(3 files)

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+
Is this a regression?  I thought I've fixed this bug before.
(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
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.
(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.
This patch handles the Lightning code only.
Attachment #223693 - Flags: first-review?(jminta)
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.
(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.
This patch fixes the day view specific problem for SunBird.
Assignee: nobody → thomas.benisch
Status: NEW → ASSIGNED
Attachment #223904 - Flags: first-review?(jminta)
This patch fixes the problem described in comment #3 for SunBird.
Attachment #223905 - Flags: first-review?(jminta)
Comment on attachment 223904 [details] [diff] [review]
patch2 (day view problem, SunBird only)

r=jminta
Attachment #223904 - Flags: first-review?(jminta) → first-review+
Attachment #223905 - Flags: first-review?(jminta) → first-review+
Attachment #223693 - Flags: first-review?(jminta) → first-review+
All patches checked in.  Thanks for the work on this!
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
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+
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
Whiteboard: [litmus testcase wanted]
Litmus testcase 2605 created
Litmus testcase 2624 created
Whiteboard: [litmus testcase wanted]
You need to log in before you can comment on or make changes to this bug.