Thanks for a bug report. That might be something with the meeting, maybe you are not listed as a direct attendee? Though even that case worked for me when I just tried.

If you've any reproducer event, could you close evolution, then run on console:
    $ CALDAV_DEBUG=all /usr/libexec/evolution-calendar-factory -w
then run evolution and repeat the issue, please? Ideally click to accept/tentative/decline when the output on the console will settle, to easily distinguish between the old and the new output there. I'm interested only in that new output. Also maybe uncheck to send notice to the organizer, to not bother him/her with the tests (it seems the Google server sends the response anyway, somehow).

As a background, the error is due to some WebDAV failure, the Google server didn't provide more information in the header, thus this is what you get in the UI. I suppose they claim more detailed information in the response body, but that is HTML, which is not usable for the evolution UI in its raw form.

I have reproduced this event and as requested.  The file with the output, though, contains all of my calendar events.  Is there anything in particular that you're looking for, that I could extract from the file so that not everything is included?

The main interesting part is just before the error, what was sent and what was received (received was the error, but I'm interested in whole server response, in case the body contains any more detailed information). From the preceding request sent to the server the event itself is not interesting, definitely not its private details, like email addresses, host names and such. On the other hand, UID, RECURRENCE-ID, RRULE and similar properties good to know about (SUMMARY, DESCRIPTION, LOCATION, ORGANIZER, ATTENDEE are those properties with private values, which you can safely remove/replace).

Reproduction Steps:

1) Use two google calendar accounts
2) Set up a meeting on one of your accounts, inviting the other account as an attendee
3) Accept the meeting from account 2 as an attendee
4) From account 1, update the time of the meeting.  Send updates to the attendees.
5) Account 2 receives another meeting update.  Accept the update.  This is when the error mentioned above occurs.

@Milan, I've posted the output from the calendar-factory as you asked, from a bit before the error to after the error occurs.  I don't see too much information in it, but perhaps you'll see something different.

Created attachment 1069277 [details]
output from: CALDAV_DEBUG=all /usr/libexec/evolution-calendar-factory -w

This is the output a bit before the error to after the error occurs from 

CALDAV_DEBUG=all /usr/libexec/evolution-calendar-factory -w

Thanks for the update. The log shows an interesting error:
> HTTP/1.1 2 Error resolving 'apidata.googleusercontent.com': No address associated with hostname

It's not the 412 error code, but looks quite serious. There can be multiple reasons for this error, being a temporary DNS issue, a proxy being involved, an /etc/hosts entry redirecting the address to a different place, and so on. Interestingly the request works and the server returns data despite the error.

I though to get part of the log before that 412 HTTP error and with it, but no problem, I'll try your steps here and let you know. I'm afraid it is related to the hostname issue though.

Okay, I am able to reproduce the error too. The related part of the log is:

> PUT /calendar/dav/user%40gmail.com/events/1od311fjm8obi0p1ojs0nr6n98%40google.com.ics HTTP/1.1
> Soup-Debug-Timestamp: 1441209312
> Soup-Debug: SoupSessionSync 1 (0x18e4e50), SoupMessage 20 (0x7f3558006740), SoupSocket 21 (0x1d251f0)
> Host: www.google.com
> User-Agent: Evolution/3.17.92
> If-Match: "63576892052"
> Content-Type: text/calendar; charset=utf-8
> Connection: close
>
> BEGIN:VCALENDAR
> ...
> END:VCALENDAR

with a response:

< HTTP/1.1 412 Precondition Failed
< Soup-Debug-Timestamp: 1441209312
< Soup-Debug: SoupMessage 20 (0x7f3558006740)
< Vary: X-Origin
< Content-Type: text/xml; charset=UTF-8
< Date: Wed, 02 Sep 2015 15:55:00 GMT
< Expires: Wed, 02 Sep 2015 15:55:00 GMT
< Cache-Control: private, max-age=0
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
< Server: GSE
< Alternate-Protocol: 443:quic,p=1
< Alt-Svc: quic=":443"; p="1"; ma=604800
< Accept-Ranges: none
< Vary: Origin,Accept-Encoding
< Connection: close
< 
< <?xml version="1.0" encoding="UTF-8"?>
< <D:error xmlns:D="DAV:"/>

The precondion it is talking about is, in my case:
> If-Match: "63576892052"

I'm investigating further. I'd guess that the event changed on the server, but the local CalDAV has an old version of the event, with a different ETag. That's when the server updates the event automatically, on the email with the time update receive. That's only an idea, though.

(In reply to Milan Crha from comment #7)
> I'd guess that the event changed on the server, but the local CalDAV has an
> old version of the event, with a different ETag.

Yes, it is. So this is a write conflict, evolution tries to rewrite an event which changed on the server, with possibly old data. There is currently no way to deal with this. It will require user interaction, to decide what to do on the write conflict. I can semi-easily force the write, as it can be done when you Refresh the calendar first, and only then Accept the change of the time of the event, but it's not good to do automatically in general.

I moved this upstream as [1]. Please see [1] for any further updates. As a current workaround update the calendar on any conflicts, then repeat the acceptance.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=754480