Closed Bug 363275 Opened 13 years ago Closed 13 years ago

Weekly layout: Custom date range shows preceding week if timezone offset is UTC+x

Categories

(Calendar :: Printing, defect)

x86
Windows 2000
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: ssitter, Assigned: mattwillis)

Details

Attachments

(1 file, 1 obsolete file)

Weekly layout: Custom date range shows preceding week if timezone offset is UTC+x

Steps to Reproduce:
1. Start Sunbird with clean profile
2. Select Week View, note week number and date range
3. Select 'File -> Print...' and choose the 'Weekly Planner' layout
4. Select print range 'Events in current view'
5. Check preview
6. Select print range 'Custom date range'
7. Check preview

Actual Results:
Step 2: 
Week view shows week 49, Sun 03-Dec-2006 to Sat 09-Dec-2006
Step 5: 
Preview shows week 49, Mon 04-Dec-2006 to Sat 09-Dec-2006, Sun 03-Dec-2006
Step 7:
From datepicker shows 03-Dec-2006 and To datepicker shows 09-Dec-2006 but
preview shows week 48, Mon 27-Nov-2006 to Sat 02-Dec-2006, Sun 26-Nov-2006

Expected Results:
Print preview shows the correct week according to the selected date range.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20061209 Calendar/0.4a1 - Build ID: 2006120903

Note: My system timezone is UTC+1. If I set the system timezone to UTC-1 the problem doesn't exist, the correct week is shown in preview.
This appears to be because printDialog.js is returning a calDateTime using the selected timezone for "Events in current view", while returning an "equivalent" calDateTime but using UTC for "Custom date range".

From "Events in current view":
start: 2006/12/10 00:00:00 /mozilla.org/20050126_1/Europe/Berlin
end: 2006/12/17 00:00:00 /mozilla.org/20050126_1/Europe/Berlin

From "Custom date range":
start: 2006/12/09 23:00:00 UTC
end: 2006/12/16 23:00:00 UTC

As a result calWeekPrinter.js prints the week with Dec 9 when "Custom date range" is selected.

The fix is to use the selected timezone for "Custom Date Range" as well.

bug 351860 may also benefit from this.
Assignee: nobody → lilmatt
Status: NEW → ASSIGNED
Attachment #248684 - Flags: first-review?(ssitter)
Comment on attachment 248684 [details] [diff] [review]
rev0 - "Custom date range" should return a calDateTime in the currently selected timezone

>+            // We return the time from the timepickers using the selected
>+            // timezone, as not doing so in timezones with a positive offset
>+            // from UTC may cause the printout to include the wrong days, as
>+            // shown below.
>+            //
>+            // Good:
>+            // start: 2006/12/10 00:00:00 /mozilla.org/20050126_1/Europe/Berlin
>+            // end: 2006/12/17 00:00:00 /mozilla.org/20050126_1/Europe/Berlin
>+            //
>+            // Bad:
>+            // start: 2006/12/09 23:00:00 UTC
>+            // end: 2006/12/16 23:00:00 UTC

I'm not sure if we really need this big comment because we do the same in many other places like calendar-event-dialog.js or unifinder.js

>             start = jsDateToDateTime(document.getElementById("start-date-picker").value);
>+            start = start.getInTimezone(calendarDefaultTimezone());
>             end   = jsDateToDateTime(document.getElementById("end-date-picker").value);
>+            end   = end.getInTimezone(calendarDefaultTimezone());

How expensive is the call to calendarDefaultTimezone? Otherwise you might call it once and store the result in a variable for the later usage.

r1=ssitter with that checked
Attachment #248684 - Flags: first-review?(ssitter) → first-review+
Attachment #248684 - Attachment is obsolete: true
Attachment #248690 - Flags: second-review?(dmose)
Attachment #248690 - Flags: first-review+
Comment on attachment 248690 [details] [diff] [review]
rev1 - Fixes duplicate calls and trims comment size

r=dmose
Attachment #248690 - Flags: second-review?(dmose) → second-review+
Patch checked in on MOZILLA_1_8_BRANCH and trunk.

-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.