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;
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).
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.
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.
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 .
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 
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)
By now this bug doesn't exist anymore. It has been fixed with patches for bug 366139.
The target milestone should be the same of bug 366139, right?
Yes, target milestone and assignee.