428715 - Between 23:00 and 00:00, the default event start date is 00:00 of the next day

Status: VERIFIED FIXED

(Calendar :: Calendar Frontend, defect)

Description

[Phil]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.13pre) Gecko/20080331 Sunbird/0.8

When I double click on a day on the month grid, the new event window comes up, but  in the last week (possibly longer/shorter), the date in the new event window is not the same as the date that I clicked on.
I start an event by double clicking on 2nd may and the event has 3rd may in the date boxes.


Reproducible: Always

Steps to Reproduce:
1. double click on 2nd may
2. check date in new events window
Actual Results:  
Date in events window says 3rd may

Expected Results:  
date should say 2nd may

I have FoxClocks 2.3.14 installed too.

I wont be checking my email address, but will check these pages, thanks for all the great work, Moz!

Comment 1

[Phil]

After changing the view from multiweek, and then back again, the problem resolved itself and cannot recreate the bug since restarting Sunbird.  

Comment 2

[Bas van den Bosch]

Then let's set it top WFM. Reporter if you experience this again, please reopen this bug. Maybe the time was between 23.00 and 0.00 and SB takes the next full hour as the start time, being the next day?

Comment 3

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

Phil, I assume the time you tried this was between 23:00 and 0:00 in your timezone. In this case, 0:00 is chosen as the start time, which is of course of the next day. There is another bug WFM/INVA bug on this I currently can't find. 

Christian, due to the number of bug reports on this, I think we should make the start time be 23:00 if in the given timeframe, what do you say?

Comment 4

[Phil]

Thanks for the speedy answer, Philipp and Christian.  I think the times for the new event at the time were 00:00 to 01:00 (not sure though)

Comment 5

[Christian Jansen]

(In reply to comment #3)
> Phil, I assume the time you tried this was between 23:00 and 0:00 in your
> timezone. In this case, 0:00 is chosen as the start time, which is of course of
> the next day. There is another bug WFM/INVA bug on this I currently can't find. 
> 
> Christian, due to the number of bug reports on this, I think we should make the
> start time be 23:00 if in the given timeframe, what do you say?
> 

Switching back to 23:00 sounds good. This is much better than jumping to the next day.

Comment 6

[Stefan Sitter [:ssitter]]

Confirming based on previous comments.

Comment 7

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

Attachment: Centralize getting the startDate - v1

Comment 9

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

Attachment: Centralize getting the startDate - v3

Fixed version also works in month view.

Comment 10

[Martin Schröder [:mschroeder]]

Comment on attachment 318018 [details] [diff] [review]
Centralize getting the startDate - v3

>Index: calendar/prototypes/wcap/sun-calendar-event-dialog.js
>===================================================================
[...]
>@@ -2046,21 +2042,18 @@ function updateDateTime() {
>                 endTime.timezone = floating();
>                 setElementValue("todo-entrydate", endTime.jsDate);
> 
>                 setElementValue("todo-has-duedate", hasDueDate, "checked");
>                 endTime.timezone = floating();
>                 setElementValue("todo-duedate", endTime.jsDate);
>             } else {
>                 // The time for the todo should default to the next full hour
>-                startTime = now();
>+                startTime = getDefaultStartDate();
>                 startTime.timezone = floating();

You should also remove the last comment.


I think you missed following occurrences of calGetStartDate/calGetEndDate:

/calendar/import-export/calHtmlExport.js
    * line 106 -- var start_a = calGetStartDate(a);
    * line 110 -- var start_b = calGetStartDate(b);
    * line 139 -- var startDate = calGetStartDate(item);

/calendar/import-export/calHtmlExport.js
    * line 140 -- var endDate = calGetEndDate(item);

This time the patch works as advertised, but I still have to look at your changes in calendar-item-editing in detail.

Comment 11

[Martin Schröder [:mschroeder]]

Comment on attachment 318018 [details] [diff] [review]
Centralize getting the startDate - v3

After having a look at the changes in calendar-item-editing.js I found another problem: When you double click in the Today pane to create an event, the event dialog always gives you an all day event because the pane passes a start date with isDate = true to createEventWithDialog(). The changes to createEventWithDialog cause that the start date argument is only cloned and not processed. Also if it was not an start date with isDate = true, it would not be adjusted if time is between 23:00 and 0:00.

Comment 12

[Stefan Sitter [:ssitter]]

> When you double click in the Today pane to create an event, the event
> dialog always gives you an all day event because the pane passes a
> start date with isDate = true to createEventWithDialog().

Philipp added this workaround to fix Bug 418115.

Comment 14

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

Attachment: Centralize getting the startDate - v4

Comment 15

[Martin Schröder [:mschroeder]]

Comment on attachment 319737 [details] [diff] [review]
Centralize getting the startDate - v4

r=mschroeder

Comment 16

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

Thanks for the through review :-)

Checked in on HEAD and MOZILLA_1_8_BRANCH

-> FIXED

Comment 17

[Andreas Treumann]

Checked with lightning 2008050719 and sunbird 20080507 -> VERIFIED.

Comment 18

[Stefan Sitter [:ssitter]]

This checkin probably regressed Bug 432998.