Closed Bug 353999 Opened 13 years ago Closed 13 years ago

fifteen- (15-) minute events make later events align too early in day/week(multiday) view

Categories

(Calendar :: Calendar Views, defect, minor)

defect
Not set
minor

Tracking

(Not tracked)

RESOLVED FIXED
Sunbird 0.5

People

(Reporter: gekacheka, Unassigned)

References

Details

(Keywords: dataloss)

Attachments

(3 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060922 Calendar/0.3a2+

Fifteen minute events make later events align too early in day view and week view (multiday view).

Reproducible: Always

Steps to Reproduce:
1. In day view or week view, drag events at 
8:15-8:30, 
9:15-9:30, 
10:15-10:30
...
18:15-18:30
19:15-19:30


Actual Results:  
By the evening, events appear to start at the top of the hour instead of 15 minutes in.

Expected Results:  
Each event start should be aligned at the 15 minute point, 1/4 the way down the hour box.

Problem does not seem to occur for 30 minute events.
Summary: fifteen- (15-) minute events make later events align to early in day/week/multiday view → fifteen- (15-) minute events make later events align too early in day/week(multiday) view
Version: unspecified → Trunk
Comment on attachment 239837 [details]
sample: .ics file of events used to create image, + day with 30 minute events

file not minimal, but shows additional days with 15minute events and a day with 30 minute events that aligns ok.
Attachment #239837 - Attachment description: test case: ics file used to create image → sample: .ics file of events used to create image, + day with 30 minute events
(patch -l -p 2 -i file.patch)

1. mPixPerMin is not generally an integer.  Therefore, cannot add rounded pixel durations to get total pixel duration.  For example, note that 
  floor(11.25) + floor(11.25) + floor(11.25) + floor(11.25) = 44, not 45

Therefore, must compute pixel duration as difference of start pixel and end pixel.

2. floating point math is not exact.  Therefore, round to get pixel coords.
For example, if mPixPerMin is 0.7, then 60 minutes should be 0.7*60 = 42 pixels, so 15 minutes should be 10.5 pixels and 30 minutes should be 21 pixels.
But (10*60 + 45)*0.7 ->   451.49999999999994
    (10*60 + 30)*0.7 ->   441
Difference is 10.499999999999943
So adding 10.5 to this produces 20.999999999999943 -> 20, not 21.

With rounding:
    (10*60 + 45)*0.7 ->   451.49999999999994  -> 451
    (10*60 + 30)*0.7 ->   441                 -> 441
Difference is 10
    (11*60 + 00)*0.7 ->   461.99999999999994  -> 462
Difference is 11, so total of differences is 21, as expected.
Attachment #239893 - Flags: first-review?
Attachment #239893 - Flags: second-review?(dmose)
Attachment #239893 - Flags: first-review?(cmtalbert)
Attachment #239893 - Flags: first-review?
Comment on attachment 239893 [details] [diff] [review]
fix rounding by using difference for duration

Looks good. Eyeballed the fix, could not run a test.
Attachment #239893 - Flags: first-review?(cmtalbert) → first-review+
Comment on attachment 239893 [details] [diff] [review]
fix rounding by using difference for duration

r=lilmatt (with dmose's blessing for me to do the r2)
Attachment #239893 - Flags: second-review?(dmose) → second-review+
Patch checked in on MOZILLA_1_8_BRANCH and trunk.

-> FIXED
Severity: trivial → minor
Status: NEW → RESOLVED
Closed: 13 years ago
OS: Windows 2000 → All
Hardware: PC → All
Resolution: --- → FIXED
Target Milestone: --- → Sunbird 0.5
Duplicate of this bug: 368690
Duplicate of this bug: 377407
You need to log in before you can comment on or make changes to this bug.