304084 - all day event gets changed to previous day

Status: RESOLVED FIXED

(Calendar :: General, defect)

Description

[Myk Melez [:myk] [@mykmelez]]

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

[Joey Minta]

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

[Robin Edrenius]

(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

[gekacheka]

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.

Comment 4

[Michiel van Leeuwen (email: mvl+moz@)]

This might be the sunbird version of bug 303826

Comment 5

[Michiel van Leeuwen (email: mvl+moz@)]

ehm, i mean bug 299327

Comment 6

[Michiel van Leeuwen (email: mvl+moz@)]

Attachment: 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.

Comment 7

[Michiel van Leeuwen (email: mvl+moz@)]

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

[Joey Minta]

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.

Comment 9

[Michiel van Leeuwen (email: mvl+moz@)]

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.

Comment 10

[Michiel van Leeuwen (email: mvl+moz@)]

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

[Joey Minta]

(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.

Comment 12

[J. Perkins]

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

[Tim]

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

[Jeff]

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.

Comment 15

[Robert William Vesterman]

(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.

Comment 16

[Michael Büttner (no reviews TFN)]

Attachment: 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.

Comment 17

[Joey Minta]

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.

Comment 18

[Joey Minta]

patch checked in.