367163 - Moving an event with timezone enabled via drag&drop changes time

Status: VERIFIED FIXED

(Calendar :: Calendar Frontend, defect)

Description

[Omar Bajraszewski]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Build Identifier: 

When I move an event that has timezone enabled using drag&drop method time changes

Reproducible: Always

Steps to Reproduce:
1.Create a new event and enable timezone for it
2.Save it
3.click on the event and move it to another day
Actual Results:  
Time of the event changes

Expected Results:  
Time doesn't change

Thunderbird version 2 beta 1 (20070113)
Lightning build 2007011605
WCAP enabler build 20070116

Comment 1

[Martin Schröder [:mschroeder]]

Omar, is this with a calendar on WCAP or with a local or other remote calendar and the prototype event dialog?

Comment 2

[Omar Bajraszewski]

(In reply to comment #1)
> Omar, is this with a calendar on WCAP or with a local or other remote calendar
> and the prototype event dialog?
> 

It was with a local calendar and with the prototype event dialog. Now I can't reproduce the problem- the prototype has been changed and now I can't enable timezone for it---> marking as WFM

Comment 3

[Omar Bajraszewski]

Attachment: Flash movie presenting the problem

Please reopen the bug

Ligntning wcap 27/02/2007 (mozilla 1.8)
Thunderbird version 2.0pre (20070227)

Comment 4

[Michael Büttner (no reviews TFN)]

Taking this one.

Comment 5

[Michael Büttner (no reviews TFN)]

I tried to reproduce this bug and it still occurs. I didn't have a look on the code, but it is clear that is has nothing to do with the dialog, it is a problem of the views. An event always has a timezone (as it always has a start/end-date), the prototype event dialog simply allows to display and eventually change the timezone. The problem will also show up for foreign (aka imported events).

I suspect that the problem happens if an event with a different timezone than the OS timezone gets modified via drag'n'drop. As the attached movie shows it doesn't happen with "Africa/Ceuta" set as timezone (which I assume has the same UTC offset as the timezone Omar has set in his OS). The same is true for me, since "Africa/Ceuta" has the same offset as "Europe/Berlin". As soon as I set the timezone to any other with a different UTC offset this bug shows up.

Comment 6

[Martin Schröder [:mschroeder]]

I tried to reproduce this bug and only succeeded in multiweek and month view.

Comment 7

[Stefan Sitter [:ssitter]]

According to Comment #5 this has nothing to do with the dialog. Therefore I think this might be the same issue/cause as reported in e.g. Bug 369331, Bug 381439 and Bug 390100.

Comment 8

[Martin Schröder [:mschroeder]]

We decided on the QA chat this bug is serious enough to block 0.7 (changes event time and has already 3 duplicates).

Comment 9

[Philipp Kewisch [:Fallen][📱📆]]

Attachment: Fix dragdop handler

The problem was that the month view used the startDate and the new box's date to calculate the time difference. Together with the fact that libical's subtractDate is broken, this probably produced a one hour offset.

What I did to fix this is to calculate the difference by subtracting the dates of the source and target box, which gives full N-day intervals when dragging.

I also went ahead and made the function I changed to be four spaced and correctly indented, but I'm attaching the diff -w version, to make it easier to review. Alignment is of course correct in the real patch. I don't mind if we change everything at once, but since thats a lot of work I think its fine to do the style changes when a function is changed and the coder feels like it.

Comment 10

[Michael Büttner (no reviews TFN)]

Comment on attachment 277298 [details] [diff] [review]
Fix dragdop handler

works like a charm, clean and elegant solution to the problem -> r=mickey.

Comment 11

[Philipp Kewisch [:Fallen][📱📆]]

Checked in on HEAD and MOZILLA_1_8_BRANCH

-> FIXED

Comment 12

[Omar Bajraszewski]

Verified with lightning 2007082405/lightning-wcap and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7pre) Gecko/20070824 Calendar/0.7pre

Comment 13

[Decathlon]

Hi,
on Sunbird 0.7 and Lightning 0.7 (and nightly build 0.8 12/8/2007) I always reproduce this issue if I try to drag a *multy-day* event (and not a single-day event) draging it by a day that isn't the first of the sequence.
When I drop the event, it jumps on a random day in the past, often the week previous, sometimes some days.
If I drag a multy-day event by the first day, the issue disapear and the new position is *always* correct.
I reproduce this with month view or mutliweek view.

The calendar is local; time zone is Europa/Rome; no others remote calendars are 
used. My OS is WinXP SP2.

Comment 14

[Stefan Sitter [:ssitter]]

(In reply to comment #13)
Decathlon, sounds like you are seeing the same issue as reported in Bug 357112.

Comment 15

[Decathlon]

(In reply to comment #14)
> Decathlon, sounds like you are seeing the same issue as reported in Bug 357112.
You're rignt. I searched on it, found several issue but not the right one so I posted here (a similar issue).
Sorry for that. Feel free to delete the post.