Using it a bit longer, it seems that delaying by 4 hours was just a random.

Some appointments are immediate (in the second when Android phone beeps), other are delayed by several hours, other appear 5 days later after the next login to the system.

Anyway, believing that appointments from Google Calendar will pop-up in Evolution in time is really naive. It makes Google Calendar in Evolution unusable.

Thanks for a bug report. I tried similar steps, only without Android phone. I created an event in google's web interface, and then I refreshed the local calendar, and I see the event on the same hour in both views (web UI and Evolution). I have also set Evolution to use system timezone, which is Europe/Prague, and the Google's calendar in Prague timezone.

I suppose, in your description, you meant Alarm, with the "Appointment appeared", did you? Do you see event at the correct time in Evolution's calendar or it's shifted there too?

Looking at the calendar, I see the appointment in the correct time.

Yes, the appointment alarms are delayed. They seem not to be shifted, but just plainly delayed by random amount of time. Sometimes they often silently stop to appear, and appear a week later after re-login. It looks like the appointment daemon silently stops or crashes.

I restart/relogin my machine only several times a month. I hibernate overnight without quitting Evolution.

I did not do any manual refresh of the calendar.

Missing reminders are caused by evolution-alarm-notify process being down, I'm almost sure with that. The shift of reminders, hmm, that is harder. My wild shot would be the hibernation, the alarm notify process probably doesn't reschedule its events, which are all maintained by GLib itself. In other words, the evolution-alarm-notify process doesn't know about the time shift caused by the hibernation.

I would like to know opinion from GLib developers, because the events are just callbacks scheduled by g_timeout_add() and similar functions.

(In reply to comment #4)
> I would like to know opinion from GLib developers, because the events are just
> callbacks scheduled by g_timeout_add() and similar functions.

Scheduling calendar alarms based on monotonic CPU time is the wrong way.

If you schedule an alarm for one hour from now using g_timeout_add() and then hibernate, the alarm will fire after one hour of CPU time + however long the machine was hibernating.

libgnome-desktop has some API for scheduling main loop timeouts based on wall clock time instead of monotonic time, which is what we want.  But the API is not public for some reason.  We could perhaps copy and paste it into Evolution for now.

http://git.gnome.org/browse/gnome-desktop/tree/libgnome-desktop/gnome-datetime-source.c

If I read it right, then the gnome-datetime-source checks once per second for expiration, which seems like an overhead. No that there are many alarms scheduled, there are about two, but anyway. The real improvement should go to GLib.

Created attachment 224073 [details] [review]
evo patch

for evolution;

This does basically the same as the above code, only in less lines and less frequently. There is done a check for the wall clock time once per minute, and if it differs from the expected time, then alarms are rescheduled. This may make up to one minute alarm delay.

Created commit 48d30dc in evo master (3.5.92+)

That works, waking up once per minutes makes more sense.

At some point we should start listening for UPower's "NotifyResume" signal so we can cut network connections, reschedule alarms, and deal with whatever other chaos suspend/hibernate causes on the internal process state.

I was thinking of UPower too, but then I got lazy. I also was thinking of GNetworkMonitor, which is listening for it too (through NetworkManager), but then I thought it would be overusing the network monitor for something not meant to be.

*** Bug 692059 has been marked as a duplicate of this bug. ***