GNOME Bugzilla – Bug 134931
all day events can span two days
Last modified: 2004-12-22 21:47:04 UTC
Apparently, all day events in ical are stored as 00:00 UTC of duration 24 hours. The applet is converting that time to localtime and can cause the event to span two days.
Mark wrote in email: > This worries me because tm_gmtoff isn't portable. I had a quick > poke at doing this portably: > > { > time_t t1, t2; > struct tm *gm_tm, *local_tm; > > t1 = time (NULL); > gm_tm = gmtime (&t1); > t2 = mktime (gm_tm); > local_tm = localtime (&t1); > > printf ("calculated utc offset = %ld, real utc offset = %ld\n", > t1 - t2, local_tm->tm_gmtoff); > } > > Unfortunately (with TZ=Pacific/Auckland for example) this can be an > hour off. I suspect something to do with daylight savings time. > I found some code that seems to work. It is from mono/metadata/icall.c. The trick is to set the DST field manually.
Created attachment 24599 [details] [review] patch to check the is_all_day field and subtract the UTC offset if necessary
*** Bug 136530 has been marked as a duplicate of this bug. ***
Created attachment 26623 [details] [review] updated patch The previous patch did not handle DST. It also computed the UTC offset using the current system time but then applied that offset to all future events, during DST or not. This patch should compute the UTC offset correctly for all times. It also adds support for multiple day events. To do this the appointment filter had to be changed to include another case besides the one where a time window encompassed an event. It now includes events that start before or at the start of the filter time window and end after the start of the filter time window. For example: a repeated event that spans a month boundary or a long event that spans more than one day. This required a new way to indicate the start time of these events in the event list view. So, if the event doesn't start on the currently selected day then display the start date in the form "%b %d" (eg. "Apr 13") instead of the time.
Actually, I think all day events in ical aren't stored in the UTC timezone, they're just stored without any timezone. The correct timezone, I think, is not UTC, but rather the default timezone of the calendar.
- I'd prefer to see calendar_client_get_date() rather than using g_object_get() - You could probably do with a /* Translators: this is what this string is for */ above the new date format string. - I'd rename adjust_date_time() to adjust_all_day() - Holy crap, the UTC offset stuff is horrible. I don't mind going ahead with this for now, but could you bug the evo guys to get this into evolution-data-server as a utility API? Also, /* copied from patch/maketime.c */ where's patch/maketime.c? Should include the full location in the comment Anyway, feel free to go ahead after fixing these few things and please do log that evolution-data-server bug. Thanks again
Committed patch to HEAD with your changes. Thanks.
*** Bug 136528 has been marked as a duplicate of this bug. ***