all day event gets changed to previous day

RESOLVED FIXED

Status

RESOLVED FIXED
13 years ago
13 years ago

People

(Reporter: myk, Assigned: michael.buettner)

Tracking

Trunk
x86
Linux
Dependency tree / graph

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

13 years ago
If I check the "All Day" checkbox when creating a new event, the event date gets
changed to the previous day.

Steps to Reproduce:

* double-click calendar or click "New Event" button to bring up dialog box;
* check "All Day" radiobox;
* click OK button.

Actual results: the event appears in the calendar on the previous day from the
date entered into the "From" and "To" text fields in the dialog box, and the
"edit event" dialog box confirms that its date was changed to the previous day.

Expected results: event appears in the calendar on the date entered into the
"From" and "To" text fields in the dialog box.

Tested on today's nightly for Linux: Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.8b4) Gecko/20050809 Mozilla Sunbird/0.2+

Note that if I subsequently edit the event, correcting the date, it stays
corrected.  The problem seems to only occur when creating an event.

Comment 1

13 years ago
Testing this I found it is only reproducable under certain conditions:
-Your system must be in a timezone that has a negative GMT offset (ie. the U.S.)
AND
-When creating the event, the time shown in the timepicker must be set to a time
before midnight *GMT*.  (ie. If you're in Eastern U.S. (GMT-5), you must  have
the timepicker set to before 19:00.)

This means you can also end up with an all-day event schedule for 1 day show up
as spanning 2 days, if your event start/end times straddle midnight GMT.

My (untested) guess is that with positive GMT offsets, you could end up with the
event showing up on the following day by using a similar procedure.

Comment 2

13 years ago
(In reply to comment #1)
> My (untested) guess is that with positive GMT offsets, you could end up with the
> event showing up on the following day by using a similar procedure.

I'm in GMT +1 (with DST, so GMT +2 atm), and the all-day events show up as they
are supposed to. I've tried with the datepicker set at 10:00 and at 22:00.

Comment 3

13 years ago
Sounds like all-day dates are not being converted correctly.
Previous discussion on this issue at bug 286070 comment 14 and bug 286070
comment 30, and some discussion of general proposals to fix the issue is in bug
296659.
Depends on: 296659
This might be the sunbird version of bug 303826
Blocks: 298936
Depends on: 303826
ehm, i mean bug 299327
Depends on: 299327
No longer depends on: 303826
Created attachment 193265 [details] [diff] [review]
patch v1

This patch makes all the newly created events to be in a timezone, instead of
floating or utc. This does fix the issue for me.
Attachment #193265 - Flags: first-review?(jminta)
The clarify why the patch works:
Without the patch, the startdate get converted to utc, and then the time part
gets chopped of. In my case, an event at 01:00:00 translated to 23:00:00 the
previous day, and so when chopping the time portion to make it all day, it was
an allday event on the previous day. Removing the conversion to utc fixes that.

Comment 8

13 years ago
Comment on attachment 193265 [details] [diff] [review]
patch v1

This patch makes things worse for me (America/New_York timezone) making all-day
events now appear 2 days prior to the selected date, instead of 1.

Also:

+	 event.startDate =
startDateTime.getInTimezone(calendarDefaultTimezone());
	 var endDate = getElementValue("end-datetime");
	 if (getElementValue("all-day-event-checkbox", "checked") ) {
	     event.startDate.isDate = true;
	     event.endDate.isDate = true;
	     // displayed all day end date is inclusive date, convert to
exclusive end date.
	     endDate.setDate(endDate.getDate() + 1); 
	 }
for all day events you need to set grab the enddate sooner, to enable this fix
to be possible.

My first instinct on this bug was to try to set all-day events in 'floating'
tz, since they should always be on the same day, regardless of the tz.	I'm not
sure if that's the right idea or not, though.
Attachment #193265 - Flags: first-review?(jminta) → first-review-
Hmmm, i think allday events should indeed be floating. But that still leaves the
problem that setting .jsDate makes the datetime to be in utc instead of
floating, resulting in a possible date change.
Does this work correctly on trunk now? (note that is isn't really fixed, but a
workaround was created in bug 306148, so we need to keep this bug open. It just
won't block 0.3a1 anymore)

Comment 11

13 years ago
(In reply to comment #10)
> Does this work correctly on trunk now? (note that is isn't really fixed, but a
> workaround was created in bug 306148, so we need to keep this bug open. It just
> won't block 0.3a1 anymore)

Yep, the workaround fixes this.  Removing from the block list.
No longer blocks: 298936

Comment 12

13 years ago
I am still seeing this behavior in the 20050915 build. Timezone is set to
America/New_York. Created all day event (recurring, if that matters) at 12pm
local time on 9/16. On next load, event is moved forward one day to 8pm on 8/15. 

Comment 13

13 years ago
In addition, any event that is set up as "all day" steps back one day for each
time you double click it to alter the event. GMT -8 here.

Comment 14

13 years ago
I'm experiencing the same problem with Alpha 1 however I've noticed a few important facts.

* This bug seems to be a remote calendar issue only. Local calendars seem uneffected in my tests. 
* This bug only exibits itself on remote calendars only after reloading or restarting the app.

These facts lead me to believe that the issue is in the gathering of the remote data as opposed to displaying data.
(In reply to comment #14)
> * This bug seems to be a remote calendar issue only. Local calendars seem
> uneffected in my tests. 

I've experienced this bug, yet have never (to my knowledge) used anything but a local calendar.

Unless Sunbird uses remote calendars out of the box as the default without the user being conscious of the difference between local and remote calendars, then this happens on local calendars.

Updated

13 years ago
Blocks: 298366

Updated

13 years ago
Assignee: mostafah → nobody

Updated

13 years ago
Assignee: nobody → dmose
(Assignee)

Comment 16

13 years ago
Created attachment 211378 [details] [diff] [review]
new patch

the timezone-adjustment in the new event-dialog did not work, since the start/enddate was already converted to a date. allday-events seem to work in any timezone now, provided that the os timezone is the same as the timezone lightning is set to. but the difference between the os/lightning timezone is related to bug #296659.
Assignee: dmose → michael.buettner
Attachment #193265 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #211378 - Flags: first-review?(jminta)

Updated

13 years ago
No longer depends on: 296659

Comment 17

13 years ago
Comment on attachment 211378 [details] [diff] [review]
new patch

r=jminta.  I'm fairly confident in our tz guessing ability, so for 0.1 this looks like a good fix.  It's also significantly simpler than my 'move minimonth to calDateTime' fix.
Attachment #211378 - Flags: first-review?(jminta) → first-review+

Comment 18

13 years ago
patch checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.