Wrong day highlighted after click in minimonth when using Day view

VERIFIED FIXED

Status

VERIFIED FIXED
13 years ago
12 years ago

People

(Reporter: ssitter, Assigned: thomas.benisch)

Tracking

Trunk
x86
Windows 2000

Details

Attachments

(3 attachments)

(Reporter)

Description

13 years ago
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

13 years ago
Is this a regression?  I thought I've fixed this bug before.
(Reporter)

Comment 2

13 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

13 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

13 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

13 years ago
Created attachment 223693 [details] [diff] [review]
patch v1 (Lightning only)

This patch handles the Lightning code only.
Attachment #223693 - Flags: first-review?(jminta)
(Reporter)

Comment 6

13 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

13 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

13 years ago
Created attachment 223904 [details] [diff] [review]
patch2 (day view problem, SunBird only)

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

13 years ago
Created attachment 223905 [details] [diff] [review]
patch3 (SunBird only)

This patch fixes the problem described in comment #3 for SunBird.
Attachment #223905 - Flags: first-review?(jminta)

Comment 10

13 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

13 years ago
Attachment #223905 - Flags: first-review?(jminta) → first-review+

Updated

13 years ago
Attachment #223693 - Flags: first-review?(jminta) → first-review+

Comment 11

13 years ago
All patches checked in.  Thanks for the work on this!
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED

Comment 12

12 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

12 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

12 years ago
Whiteboard: [litmus testcase wanted]

Comment 14

12 years ago
Litmus testcase 2605 created

Comment 15

12 years ago
Litmus testcase 2624 created

Updated

12 years ago
Whiteboard: [litmus testcase wanted]
You need to log in before you can comment on or make changes to this bug.