GNOME Bugzilla – Bug 753764
Can't move recurring 24h calendar entries back one day
Last modified: 2015-08-20 11:23:39 UTC
3.12.11 supplied by openSUSE. I just added an event to my calendar. Set it for "all day", set it to recur every 1 year forever. Realised it was on the wrong day. It should have been one day earlier. Opened it, edited it to the earlier day, save for all instances. Nothing has happened. Open it again, try again. Just can't make it change day at all. So deleted all instances and created it on the correct day. Whilst this was only a little inconvenient, I can imagine it might be hiding a much more general bug that can become aggravating or lead to data loss. It should be investigated.
Thanks for a bug report. I can reproduce this with an On This Computer/Personal calendar in the 3.16.5 and current development version as well. Similar with a CalDAV backend, talking to a Google server. I agree this is good to investigate.
This required changes on the evolution-data-server and evolution side. The data server change was about computing floating times in the default ECalClient time zone, thus the RECURRENCE-ID matches recalculated DTSTART in the UI. The evolution change was about preserving timezone setting for DTSTART and DTEND of recurring events, thus their times are not treated (and eventually saved) as floating times. The reason why you noticed the issue was that the DATE value of the all-day event calculated in the system timezone was one day less, thus the UI had DTSTART on the correct day, but RECURRENCE-ID on the previous day, thus the date change to one day less resulted into matching RECURRENCE-ID and the DTSTART, which the code understands as "keep the dates as in the master component", thus it returned the DTSTART and DTEND to the previous value, the original date. Created commit_e7b4d6c in eds master (3.17.91+) [1] Created commit d6bf261 in evo master (3.17.91+) [1] https://git.gnome.org/browse/evolution-data-server/commit/?id=e7b4d6c