GNOME Bugzilla – Bug 766346
Incorrect times provided in e_cal_recur_generate_instances()
Last modified: 2016-08-22 17:24:02 UTC
All day events from google calendar integration are showing up as correct day in gnome calendar plus one more day, being duplicated into two days. gnome-shell-3.20.2-1.fc24.x86_64
I can't reproduce this - all day Google events show up correctly in both the shell's calendar and gnome-calendar here. Can you reproduce the issue in gnome-calendar or evolution?
Tried evolution and it seems events are displayed correctly there. I am having this issue in gnome-shell's calendar in upper menu.
Created attachment 327744 [details] gnome-shell calendar
I can confirm this bug, even without use of Google Calendar. Many 'all day events' (but not all) are shown as if their durations were 2 days in the Gnome-shell calendar popup. Their durations are correct in Evolution or Gnome Calendar. The problem occurs also for the birthday events automatically created by Evolution : 2 days in Gnome-shell, 1 in Evolution / Gnome Calendar. Everything was ok with gnome-shell 3.18.
I am also experiencing the same problem with a calendar from owncloud, concretely (owndrive). All day events are spread along two days in the gnome-shell calendar. However, they display properly on gnome-calendar.
Created attachment 327968 [details] Pentecost: one day in Gnome Calendar
Created attachment 327969 [details] Pentecost: 2 days in Gnome Shell (1/2)
Created attachment 327970 [details] Pentecost: 2 days in Gnome Shell (2/2)
*** Bug 766801 has been marked as a duplicate of this bug. ***
Can also confirm this behavior. In evolution and gnome-calendar the entries are correct. Maybe that's an issue because of the leap year.
(In reply to petres from comment #10) > Maybe that's an issue because of the leap year. I doubt it. As I said in comment #1, I can't reproduce the issue, and according to comment #4, only some all-day events are affected.
Could someone affected by this bug run: CALENDAR_SERVER_DEBUG=1 /usr/libexec/gnome-shell-calendar-server --replace and provide the output? My current guess is a timezone issue, though there haven't been any changes in 3.20.x in that regard (but that's true for all the calendar event handling really).
> gnome-shell-calendar-server[3307]: 20:51:11.537: Using timezone Europe/Vienna > gnome-shell-calendar-server[3307]: 20:51:11.537: Connected to the session bus > gnome-shell-calendar-server[3307]: 20:51:11.538: Acquired the name org.gnome.Shell.CalendarServer > gnome-shell-calendar-server[3307]: 20:51:11.708: Handling GetEvents (since=1451300400, until=1454929200, force_reload=true) > gnome-shell-calendar-server[3307]: 20:51:11.708: Loading events since 20151228T110000Z until 20160208T110000Z > gnome-shell-calendar-server[3307]: 20:51:11.778: on_objects_added for calendar > gnome-shell-calendar-server[3307]: 20:51:11.779: on_objects_added for calendar > gnome-shell-calendar-server[3307]: 20:51:11.779: on_objects_added for calendar > gnome-shell-calendar-server[3307]: 20:51:11.798: Handling GetEvents (since=1451300400, until=1454929200, force_reload=false) quite uninformative, is there an option to get the details of each object?
This happens on a fresh Fedora 24 install so I doubt is a configuration issue. This is either tied to some locales or a specific gmail accounts. To me it happens on all all-day events as I have added google holidays calendar to my specific and all holidays are dupes, and also all-day events that I add.
Btw, my timezone is same as of petres.
On ArchLinux : > CALENDAR_SERVER_DEBUG=1 /usr/lib/gnome-shell/gnome-shell-calendar-server --replace > gnome-shell-calendar-server[15316]: 21:29:05.858: Using timezone Europe/Paris > gnome-shell-calendar-server[15316]: 21:29:05.859: Connected to the session bus > gnome-shell-calendar-server[15316]: 21:29:05.860: Acquired the name org.gnome.Shell.CalendarServer > gnome-shell-calendar-server[15316]: 21:29:05.915: Handling GetEvents (since=1461581100, until=1465209900, force_reload=true) > gnome-shell-calendar-server[15316]: 21:29:05.915: Loading events since 20160425T104500Z until 20160606T104500Z > gnome-shell-calendar-server[15316]: 21:29:05.987: on_objects_added for calendar > gnome-shell-calendar-server[15316]: 21:29:05.988: on_objects_added for calendar > gnome-shell-calendar-server[15316]: 21:29:05.988: on_objects_added for calendar > gnome-shell-calendar-server[15316]: 21:29:05.988: on_objects_added for calendar > gnome-shell-calendar-server[15316]: 21:29:05.988: on_objects_added for calendar > gnome-shell-calendar-server[15316]: 21:29:06.028: Handling GetEvents (since=1461581100, until=1465209900, force_reload=false)
(In reply to mirandir from comment #16) > On ArchLinux : > > CALENDAR_SERVER_DEBUG=1 /usr/lib/gnome-shell/gnome-shell-calendar-server --replace > > [...] > > gnome-shell-calendar-server[15316]: 21:29:05.915: Handling GetEvents (since=1461581100, until=1465209900, force_reload=true) > > gnome-shell-calendar-server[15316]: 21:29:05.915: Loading events since 20160425T104500Z until 20160606T104500Z That's for the current month, however the values are slightly different from what I'm seeing here: > gnome-shell-calendar-server[10464]: 23:14:20.894: Handling GetEvents (since=1461580200, until=1465209000, force_reload=true) > gnome-shell-calendar-server[10464]: 23:14:20.894: Loading events since 20160425T103000Z until 20160606T103000Z This shouldn't matter in that case, however it is very likely that the same applies to the dates in the event[0], which would then have the observed effect. Still, it's not yet clear what's going on here ... [0] https://git.gnome.org/browse/gnome-shell/tree/js/ui/calendar.js#n269
(In reply to Florian Müllner from comment #11) > As I said in comment #1, I can't reproduce the issue I figured out that part - I had libical 1.0.1 in my prefix, with 2.0.0 I see the issue as well.
Created attachment 328848 [details] [review] Use UTC for all day events
Created attachment 329097 [details] [review] all day events starting at local time at midnight
Review of attachment 329097 [details] [review]: That's a workaround, not a fix. For what it's worth, this is the commit the broke it: https://git.gnome.org/browse/evolution-data-server/commit/?id=65c85d94d3e5aa So either the correct fix is in evolution-data-server, or the previous behavior we rely on was buggy and gnome-shell-calendar-server needs adjusting.
True, its only a workaround. What would be the expected behaviour from gnome-shell-calendar-server, should received all day events start and end at midnight in local time?
Well, considering that what triggered the issue was the changed implementation of e_cal_recur_generate_instances() in evolution-data-server, it is highly likely that it is a regression there.
Do we need to open up new bug report or maybe reassign this one?
Created attachment 330969 [details] [review] recur: Use correct tz to resolve DATE endtimes in generate_instances() Since commit 65c85d9, e_cal_recur_generate_instances() is a small wrapper around e_cal_recur_generate_instances_sync() when compiled against libical-2.0. However unlike the previous code, the time_t endtime passed to the instance callback is resolved without timezone information in the case of DATE values, instead of using the default timezone.
So after digging into this for a while, this seems to be the difference between the original code and the compatibility code added in commit 65c85d9. It fixes the issue for me, but then my knowledge of either evolution-data-server or libical is close to zero, so I'm not super-confident that it's actually the correct fix. Let's see what e-d-s developers have to say ...
Thanks for a bug report and the patch. The DATE values are not meant to be influenced with a timezone, as defined in RFC 5545, section 3.2.19 [1]: The "TZID" property parameter MUST NOT be applied to DATE properties and DATE-TIME or TIME properties whose time values are specified in UTC. Thus converting the end time in the DATE format looks suspicious. Could someone upload here the definition of the event which is split in the GNOME Shell calendar, but not in the evolution or gnome-calendar? The even can be saved fromt he evolution (in the context menu) or can be faound in ~/.cache/evolution/calendar/<source-uid>/calendar.ics, where anything between BEGIN:VEVENT and END:VEVENT is interesting (search by summary for example). This difference (wrong in one, correct in another) suggests that the problem is in the GNOME Shell calendar. I do not know the GNOME Shell calendar code, thus I'm asking rather than reading myself: does it subtract one day from the end date or one second from the end time, when calculating the interval for which the event is declared? The reason to do so (if the DTEND doesn't match the DTSTART) is that the DTEND is not inclusive date/time, as specified in the RFC 5545 [2]. [1] https://tools.ietf.org/html/rfc5545#section-3.2.19 [2] https://tools.ietf.org/html/rfc5545#page-54 , the second paragraph there
Created attachment 331234 [details] Holiday from evolution As I don't have anything in path suggested, I went with the other option and saved one whole day event from evolution, which is a holiday from google calendar. That day is showing as single day in evolution, but spreads into second day in gnome calendar. Thanks for having a look at it.
(In reply to Milan Crha from comment #27) > Thus converting the end time in the DATE format looks suspicious. It is what e_cal_recur_generate_instances_of_rule() does, which is still used when evolution-data-server is not compiled with libical-2.0 support. Unless it is really intentional that the ECalRecurInstanceFn callback passed to e_cal_recur_generate_instances() receives different instance_start/instance_end times depending on whether HAVE_LIBICAL_2_0 is defined or not, there is either a bug in the non-ical2 branch (and thus all previous e-d-s versions), or in the newly added code (either e_cal_recur_generate_instances_sync() or the compatibility layer to translate between the two apis). (In reply to Milan Crha from comment #27) > This difference (wrong in one, correct in another) suggests that the problem > is in the GNOME Shell calendar. They simply use different APIs. The gnome-shell calendar code was inherited from gnome-panel (so that's broken as well) and worked correctly until the e-d-s commit pointed out above. > I do not know the GNOME Shell calendar code, > thus I'm asking rather than reading myself: does it subtract one day from > the end date or one second from the end time, when calculating the interval > for which the event is declared? Sorry, I don't quite understand the question (this is hardly my field of expertise) - gnome-shell calendar used to do the following(*): - call e_cal_client_get_object_list_sync() to get a list of events for a specified time range (the currently visible month) - call e_cal_recur_generate_instances() on each object to get the list of occurrences in the same range (i.e. the visible month) As I understand the e-d-s code, any adjustments to DTEND are already done for us? Also times are not off by one day or one second, but by the timezone offset, and only when e-d-s is compiled against libical-2.0. We surely are not expected to adjust (or not adjust) values depending on compile-time options of evolution-data-server? (*) we switched to e_cal_client_generate_instances_sync() just last week, but that's using e_cal_recur_generate_instances() internally, so this issue still applies
*** Bug 768984 has been marked as a duplicate of this bug. ***
*** Bug 769019 has been marked as a duplicate of this bug. ***
(Removing Google Calendar from the bug title.)
Okay, despite the RFC, both functions claim they apply the default timezone to DTSTART/DTEND if no other timezone is set for the event, which my change broke earlier. The above proposed patch didn't work for the event attached at comment #28, thus I made a slightly different changes myself. Created commit d617d18 in eds master (3.21.90+) Created commit 45b7b97 in eds gnome-3-20 (3.20.5+)
(In reply to Milan Crha from comment #33) > I made a slightly different changes myself. > > Created commit d617d18 in eds master (3.21.90+) > Created commit 45b7b97 in eds gnome-3-20 (3.20.5+) Thanks for looking into this (and fixing it)!
*** Bug 766210 has been marked as a duplicate of this bug. ***
*** Bug 769483 has been marked as a duplicate of this bug. ***
That works now, thanks !
Sadly, this bug is not fixed for me with gnome-shell 3.20.3 and evolution-data-server 3.20.5. My all-day events are still on two days in gnome-shell. It's even worse, because the workaround in the comment 20 doesn't work anymore.
(In reply to mirandir from comment #38) > Sadly, this bug is not fixed for me with gnome-shell 3.20.3 and > evolution-data-server 3.20.5. My all-day events are still on two days in > gnome-shell. Weird. When it works for others, why not for you? There might be some reason. I do not know, did you just install the new data server, or you did restart the evolution-calendar-factory after it had been installed?
(In reply to Milan Crha from comment #39) > Weird. When it works for others, why not for you? There might be some > reason. I do not know, did you just install the new data server, or you did > restart the evolution-calendar-factory after it had been installed? I even rebooted after each installation, to be sure.
(In reply to mirandir from comment #40) > I even rebooted after each installation, to be sure. Good. Could you open evolution, right-click one of the offending events and "Save as iCalendar..." it, then sanitize any private information from it and share it here, please?
And voila: https://www.dropbox.com/s/ec5yupwmsdvy20q/Sortie_From_the_vault_lore.ics?dl=0
The problem seems solved with gnome-shell 3.20.4.
(In reply to mirandir from comment #42) > And voila: > https://www.dropbox.com/s/ec5yupwmsdvy20q/Sortie_From_the_vault_lore.ics?dl=0 I just checked and the event it defined in the way the change in eds fixes. (In reply to mirandir from comment #43) > The problem seems solved with gnome-shell 3.20.4. Ah, good, you were quicker than me.