Modifying the start date of a new All day event causes the timezone link activation and a change in the timepicker of the end date



7 years ago
5 years ago


(Reporter: Decathlon, Assigned: Decathlon)





7 years ago
Reproducible: Always

Steps to reproduce:
1. create a new event;
2. click on menu Options->Timezone;
3. click on the "All day event" checkbox;
4. click on the "Start date" datepicker;

Actual result:
the end date timepicker is disabled but its time changes from 0:00 to 1:00, moreover, after step 4, the timezone text of the end date changes from "Local time" to the default timezone defined in Lightning, and becomes enabled allowing to select a different timezone. If this happens, the event will be saved with an end date in the date-only format but with a time zone identifier TZID e.g.


that shouldn't be allowed (bug 388656).

Expected results:
the event is an All day one, hence the timepickers should always show the time 0:00 and the timezone links should always be disabled in order to avoid to select a Time Zone Identifier.

In general, changing the start and the end time, before performing step 3 in s.t.r., causes the datepicker issue with a time that is the difference between the end time and the start time e.g. if you set a start-end time to 3:05-5:45, the end timepicker will show 2:40 instead of 0:00.

Without changes to the timezone, the event just created is corrected; reopening the event, both timepickers show correctly the time 0:00.

Not completely sure if it has been already reported because Lightning 0.9 too has this bug.

Comment 1

7 years ago
Actually in steps to reproduce, after step 4 the text link doesn't change to the default timezone defined in Lightning, but it remains "Local time", though it becomes enabled.

Comment 2

7 years ago
The problem here is that when the function updateTimezone() is called, the variable gEndTime is date-time (isDate=0), instead it should be date only (isDate=1), and this causes the activation of the timezone link inside the function updateTimezone [1].
It seems that the wrong value comes from the function dateTimeControls2State()  because it updates gStartTime but not gEndTime when the event is an all day [2] 


Comment 3

7 years ago
I added a fix for this bug in the patch(es) for Bug 366139.
If that patch won't be backed-out, this bug should be considered fixed.
Could someone please confirm?
qawanted: Check if this has been already fixed. (per comment#3)
Keywords: qawanted

Comment 5

5 years ago
By now this bug doesn't exist anymore. It has been fixed with patches for bug 366139.
Last Resolved: 5 years ago
Keywords: qawanted
Resolution: --- → FIXED

Comment 6

5 years ago
The target milestone should be the same of bug 366139, right?
Target Milestone: --- → 1.0b3
Yes, target milestone and assignee.
Assignee: nobody → bv1578
You need to log in before you can comment on or make changes to this bug.