Bug 1547743

Thanks for a bug report. Could you right-click the event and choose Save as iCalendar, then edit the file and remove everything private from it (like censor with 'xxxxx' or anything like that, then attach it here, please? That will show what evolution created out of it. It would be also interesting to know how is the event stored on the server, but that means deleting your local cache and re-downloading all the events from scratch, while the only way to find the correct event would be to check with the time zone, which is hard to guess what it would be. An easier way might be to ask you colleague to add another event into the calendar, a test one, while you'll have running the calendar factory like this:

   $ EWS_DEBUG=2 /usr/libexec/evolution-calendar-factory -w

from a terminal. Then you run evolution and will receive the event. The output on the console will contain some "<MimeContent" text (quoted for clarity only), which is base64 encoded iCalendar representation of the event, similar to what you get when saving the event in Evolution (thus it requires censoring as well). Outer elements, basically whole server response with this MimeContent, is important, because it contains timezone definition for the start and the end times, as returned and stored on the server.

Created attachment 1404103 [details]
iCal file for a repeated appointment made in New Zealand time zone (from the originator's calendar).

Created attachment 1404104 [details]
iCal file for a repeated appointment made in New Zealand time zone (from my calendar, but after my collaborator canceled it).

Sorry to take so long to follow up. For some reason, I wasn't able to get the debug log working, but I did experiment with my New Zealand collaborator. We discovered that the bug seems to only show itself in repeated appointments.

I missed grabbing the iCal version of the repeated appointment before my collaborator canceled it, but I am posting the canceled one from my calendar. He also sent me a copy of the iCal file from his calendar and I am posting that.

If this isn't enough, I can run the experiment again. Not sure what I did wrong with the debugger, though.

I confirm this issue. Unfortunately I'm not able to save my appointment to iCal, it doesn't create a file and don't report any error.
evolution-ews-3.26.5-1.fc27.x86_64

Thanks for the update. I see that the event in Outlook saves with:
   DTSTART;TZID="New Zealand Standard Time":20180302T150000
   DTEND;TZID="New Zealand Standard Time":20180302T160000
while in Evolution it saves with:
   DTSTART:20180302T150000
   DTEND:20180302T160000
That missing TZID parameter means that the time in Evolution is considered as floating, which means the time in whatever timezone the user uses. One won't notice if using the same timezone as the other user/OWA/client.

I tried it locally and I see that some timezones are not properly recognized and the worse they are not even saved in the local cache, which breaks time calculation. Recurring events have converted the timezone to local, which may or may not be correct too.

Created attachment 1404376 [details]
eds patch

for evolution-data-server;

This is a patch which helped me. I made a test build with it included, it can be downloaded from here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=25502633
click on one of the buildArch links to download the one you need and download packages from there, then update them on your machine.

To have the patch properly working:
a) close evolution and any 3rd-party application which connects to evolution-
   calendar-factory, like GNOME Calendar, GNOME ToDo and others
b) see what factory-subprocess processes left runnning and kill them all:
   $ ps ax | grep evolution-calendar-factory-subprocess
   $ kill -TERM $PID
c) go to ~/.cache/evolution/calendar/ and delete all subdirectories there;
   this will cause re-download of the server content to the local cache
d) kill also other evolution processes now:
   $ evolution --force-shutdown
e) start evolution

Once the items are downloaded, they should be shown in correct time, possibly with different timezone set (except for recurring events).

Please note that updates-testing will receive 3.26.6 release shortly, thus make sure you'll not install it before you end with this test build (in case you update packages also from updates-testing).

That does seem to solve the problem, at least insofar as the appointments that previously had the wrong time now have the correct time.

Nice, thanks for the confirmation. I'll commit it for 3.28.1 the next week (the sources are frozen at the moment, thus it will miss 3.28.0).

I also filled [1] for some follow up work.

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

(In reply to Milan Crha from comment #9)
> Nice, thanks for the confirmation. I'll commit it for 3.28.1 the next week
> (the sources are frozen at the moment, thus it will miss 3.28.0).

Thanks.

You'll backport to F27 also, right?

(In reply to Matthew Saltzman from comment #11)
> You'll backport to F27 also, right?

Nope, I didn't plan to do it, even there had been a 3.26.6 release yesterday. Maybe the change has some side effects I'm not aware of at the moment, which would be hard to fix in 3.26.x, because that one is basically death in upstream already. The 3.26.6 release was rather an exception, to address particularly bad issue.

So I need to avoid evolution-data-server updates until F28?

(In reply to Matthew Saltzman from comment #13)
> So I need to avoid evolution-data-server updates until F28?

True. Here's a test build with the patch on top of 3.26.6, which is the last version in 3.26.x series:
https://koji.fedoraproject.org/koji/taskinfo?taskID=25555180

Created commit d55d07356 in eds master (3.29.1+) [1]
Created commit cf99cf12d in eds gnome-3-28 (3.28.1+)

[1] https://git.gnome.org/browse/evolution-data-server/commit/?id=d55d07356

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

(In reply to Milan Crha from comment #14)
> (In reply to Matthew Saltzman from comment #13)
> > So I need to avoid evolution-data-server updates until F28?
> 
> True. Here's a test build with the patch on top of 3.26.6, which is the last
> version in 3.26.x series:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=25555180

Where can I get the build RPM?  I don't see any on the koji link above.

(In reply to Milan Crha from comment #14)
> (In reply to Matthew Saltzman from comment #13)
> > So I need to avoid evolution-data-server updates until F28?
> 
> True. Here's a test build with the patch on top of 3.26.6, which is the last
> version in 3.26.x series:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=25555180

Where can I get the built RPM (x86-64)?  I don't see any on the koji link above.

(In reply to Louis van Dyk from comment #18)
> Where can I get the built RPM (x86-64)?  I don't see any on the koji link
> above.

It had been deleted, because that scratch build had been done long time ago. I'm rebuilding it at:
https://koji.fedoraproject.org/koji/taskinfo?taskID=26456379