Just changed to a CalDAV-based calendar. Adding some past-dated events (e.g., of February 2026) for continuity and reference I found that the events are written to the server and sync’d to my Android phone while Evolution briefly shows them, then removes them again from the calendar. Is there any switch or setting to keep these events permanently?
-nothing follows-
Hi,
no idea what Evolution version you have, but try to open Properties of
the CalDAV calendar (seen in the context menu, when you right-click the
calendar name in the list of the calendars), and close to the bottom is
a past event time limit, which you can set to 0 to have shown all
events. It had been added not long ago.
Bye,
Milan
Hi Milan,
thanks for the update. My version is 3.46.4-2+deb12u1 which probably is a tad too old, owing to the fact that it is from the official MX Linux 23 repository. The CalDAV synchronization software I use on Android received that same very option you are mentioning only a few days ago. I’ll just let it go for the time being, hoping that the repo will be updated sometime soon.
Cheers, Norbert
Hi,
it’s truly a very old version. It’s as old as things like power saving
mode (as set in the system) can have an influence on this. Do you have
enabled the power saving mode? Otherwise I do not recall what else
could influence to not download all the events from the calendars.
Unless it’s a GUI/search thing. Check the bar above the events, it may
say:
Show: [ Any category ] Show: [ ]
If you ask why the power saving mode, then in those times it was looked
on the calendar refresh as an expensive operation, which should not
worth to consume your precious battery, thus in the power saving mode
the full calendar refreshes are paused. The latest version has an
option to respect the power saving mode, but it’s disabled by default,
because it was not obvious why the calendars can save events, but
“cannot” read changes from the server.
Bye,
Milan
Milan:
Using a different distro (Linux Mint) I installed the latest Evolution version 3.60.2 (by Flathub.org) and checked the PastTimeEvent Limit making sure it is on ZERO. Also the power save mode is off. Unfortunately, the effect is still the same - an event added in the past (e.g., 1-APR-2026) shows for a brief period, then disappears. Interestingly enough my CalDAV Server does indeed show and keep the appointment.
Could it be that past events added LATER will not be accepted by the Evolution Calendar but will subsequently keep entries that age “naturally”, i.e., current entries will be kept but not those added arbitrarily with a past date?
I’m just “fishing in the dark” so-to-speak.
Regards, Norbert
Hi,
I can add an event on March 31st, 2026 to a CalDAV calendar I’ve
configured for years and it stays in the GUI.
Try to add an event with a unique summary you never used before, say
like “aaabbbcccddd” (quotes for clarity only). Save it to your CalDAV
calendar and when it goes away, check whether it’s in the local cache,
which is either
~/.cache/evolution/calendar/<uid>/...
for the packaged version or
~/.var/app/org.gnome.Evolution/cache/evolution/calendar/<uid>/...
for the Flatpak version. Simply search all files in the
…/evolution/calendar/ directory and its subdirectories for inclusion
of that unique string in the Summary.
As it’s a past event, can the server mark it as cancelled? What does
evo have set for you at menu Edit->Preferences->Calendar and Tasks->
Display tab->“Hide cancelled events” option, please?
In any case, if you can find the event in the local cache, then it’s
some filtering setting, which hides the event from you.
We could involve also CalDAV debugging to see what evo sends to the
server and what the server returns. That can be enabled with:
flatpak kill org.gnome.Evolution
CALDAV_DEBUG=1 flatpak run org.gnome.Evolution
and when you save an event there will be some PUT request, most likely
followed by a GET request. You can compare the parts between
BEGIN:VEVENT and END:VEVENT to see what the server changed. The PUT
request should receive a response “201 Created”, if I recall correctly.
Do not share the log in the public, it contains raw communication and
can expose your credentials, server addresses and anything & everything
private.
Bye,
Milan
Milan:
That’ll take me a while since I am currently wrestling with the Flatpak version - seems to be corrupted since it is not updating any calendar right now while my package-based instances of Evolution are working just fine.
I’ll get back to you once I have results.
Thanks, Norbert
Milan:
All right - here goes:
I have installed yet another distro (Manjaro 6.12.96-1-MANJARO with Cinnamon 6.6.9) which comes packaged with Evolution 3.60.2 - and the same problem - whenever I add an event in the past, it is being entered, and as soon as I touch the “refresh” button - poof - it’s gone.
It is, however, contained in the main CalDAV calendar bright and clear but it does not show in my Android-based calendar. It seems to me that the CalDAV server may be playing some unwanted role.
The Past Event Retention Period Limit has been set to 0.
I have enabled debugging for the calendar engine and logged the events around a test event called “Test for DEBUGGING5” (minus the quotes) as shown in the screen shot above. I have subsequently briefly analyzed the log file and stripped off the calendar URL as well as my credentials.
Can I upload it to a private destination for you to analyze?
Please advise - and thanks for your help.
Regards, Norbert
It seems to me that the CalDAV server may be playing some unwanted
role.
Hi,
it surely looks like that.
Can I upload it to a private destination for you to analyze?
I do not have any such private pastebin. You can send the log directly
to my address, only reference this conversation in the mail, thus I
know what it is for.
Thanks and bye,
Milan
Hi,
thanks for the log. I see the server returned the component slightly
modified, but nothing what would cause loss of it in the GUI (it
advertises a bit different timezone definition, but still compatible
with what was sent to the server; the component’s DTSTAMP is almost a
minute in the future and it added PRIORITY:0, but otherwise it’s the
same).
When you open the Calendar view and switch to the Week View (View->
Current View->Week View), then choose above the event list:
Show: Any Category
and in the “Search” when you click on the magnifier icon on the left
and pick there “Summary contains” and then when you type into the entry
the “debug” or “test” word (quotes for clarity only) and then press
Enter, then it’ll filter the events in the view. There are left/right
arrows on the right of the “Search” entry, which you can use to quickly
search for the events satisfying the search criteria.
Will that find/show the event, please?
I tried to import the event the server returned to my CalDAV calendar
and I can find it on April 1st, 2026 using the above described method.
You can use Search->Clear to turn off the filtering, which effectively
empties the “Search” entry (it does not touch the Show combo).
Bye,
Milan
Hi Milan,
still no go.
Just FYI and verification - the event in question is
Evolution’s settings (Flatpak 3.60.2 on Linux Mint) show a 0 (zero) for Past Time Event Limit, and a SPACE in the pertinent field in the DAVx5 configuration (4.5.18-ose) on Android.
Do you think I should open a ticket with my DAV provider just for grins?
Thanks & regards,
Norbert
Hi,
I suppose you tried the steps with the Search/Show filter and it did
not help.
As you switched from the packaged version to the Flatpak version (and
the latest stable, which is great), could you re-check whether any file
under
~/.var/app/org.gnome.Evolution/cache/evolution/calendar/
contains the “debugging” text, or any other unique text from the test
component, please? It should.
Even, I did re-read the log you sent me and even it shows the event is
PUT to the server and it can be read back with a GET request, the
following REPORT does not contain the event UID (it starts with
e6b13ad). The first report is limited to a time range
<time-range start="20260620T113554Z" end="20260829T113554Z"/>
which cannot match the event in April, but then the second REPORT
runs with unlimited time, where the server should report more events.
It’s done that way in the CalDAV, to show the events around “today”
quickly and sync the old events locally later.
The log does not seem to be cut, then neither of the REPORT-s
returned the created event, then the CalDAV code dropped it from the
locally cached events, thus the event disappears (and is not in any
file in the cache path I mentioned near the beginning of this message).
As it worked for me here, I did think it’s a leftover filter in the
GUI, it sometimes happens unnoticed (for example when mouse wheel is
used above the combo boxes), but right now it looks like something with
the server after all, especially if more apps are affected.
You mentioned the DAV provider, is it the web interface of the server
or a standalone app or such? I’m wondering whether it uses some other
protocol to connect to the server and to get events from the server
than the CalDAV. When you look into the log you sent me earlier you can
check how the server identifies itself in the Server: header (it is
not always the same, interestingly, a “Created” response shows a
different value than for example the preceding response to the
PROPFIND request for the getctag of the calendar).
As I look it on now, it does worth to report to the server admins,
maybe they will find some problem (or there’s a setting accessible in
the Web interface only?).
Bye,
Milan