Description of problem: A colleague added an appointment to my Exchange calendar from New Zealand (I am in US Eastern time zone). The appointment shows up in my Fedora Evolution calendar with a time that is 16 hours later than the actual scheduled time. The time zone listed in the appointment is correct and the entry show up with the correct time in my Android phone calendar and my CentOS 7 calendar (evolution-3.22.6-10.el7.x86_64) Version-Release number of selected component (if applicable): evolution-3.26.5-1.fc27.x86_64 How reproducible: Always, I think Steps to Reproduce: 1. Find a user in New Zealand to create an appointment in an Exchange calendar with time zone set to US Eastern. 2. Display the appointment in Evolution. 3. Actual results: Appointment shows at wrong time. Expected results: Appointment shows at correct time. Additional info: New Zealand time is in fact 16 hours ahead of US Eastern (GMT+13). I would conjecture that the error was on the part of the appointment creator, except that the appointment shows correctly in my other calendars. An appointment set up with Auckland time zone displays at the correct time in all my calendars, including this one. Have not tested to see if Google calendars have the same problem.
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