GNOME Bugzilla – Bug 708143
Created appointment is one hour later
Last modified: 2015-04-28 15:17:41 UTC
When creating an appointment, my colleagues (using Outlook as a client) receive a request for one hour later than the original time. In my calendar in evolution, the original time is shown. When I check with Outlook Web Access, the time there is also one hour later. I guess this has something to do with time zones, but both Evolution and Outlook are set to Europe/Berlin.
Which Outlook version? Which Linux distribution?
Mainly Outlook 2013, but occurs with all versions, including Outlook Web Access. Arch Linux with evolution-ews 3.8.5
Hi, I can confirm this bug. Outlook version is 2010. Linux distribution is also Arch Linux. Evolution is 3.8.5.
Thanks for a bug report. I tried to reproduce this, but it works fine for me. What I did: a) create an appointment at 2PM of Europe/Berlin in an exchange calendar (mine server version is 2010) b) open the OWA interface of the server and check what's there. I see the event also at 2PM, on the same day. You are right that this is related to timezones. Mine OWA interface has set timezone "(UTC+01:00) Belgrade, Bratislava, Budapest, Ljubljanka, Prague" in Options->See All Options...->Settings->Regional->Current timezone. Could you check your timezone setting in OWA and/or Outlook, what UTC offset they use, please? Also check your tzdata package version, it provides timezones with their UTC offsets and daylight saving change information. Could you create a test appointment in evolution, and one in Outlook or OWA, and save them both from evolution to a file (right click it and in the context menu is Save as iCalendar option), then remove any private information from them, and attach them here, please?
Created attachment 256428 [details] Appointment at 2PM from Evolution
Created attachment 256430 [details] Appointment at 2PM from OWA
When trying to reproduce this, I stumbled upon another strange phenomen: 1. Start Evolution 2. Create an Appointment -> There is a field for the time zone, filled with UTC, despite the configured time zone being Europe/Berlin 3. Create another Appointment -> There is no field for the time zone The time zone field only reappears after closing and starting Evolution again, an only the first time an appointment is created. The time zone of OWA is (UTC+01:00) Amsterdam, Berlin, Bern, Rom, Stockholm, Wien. My tzdata version is 2013f.
Thanks for the update. I think I see the problem, it's due to libical 1.0, which stores all the timezone history in the vEvent, which confuses the exchange server, thus it returns a different timezone and the events are shifted. Could you try to downgrade your libical to 0.48 version, restart evolution-calendar-factory and do the same steps, whether it'll help? If it will, then it'll prove my hypothesis.
When I downgrade to libical 0.48 and try to start evolution, I get evolution: error while loading shared libraries: libical.so.1: cannot open shared object file: No such file or directory By the way: In the meanwhile it is evolution-ews 3.10.1, still with the same problem.
(In reply to comment #9) > When I downgrade to libical 0.48 and try to start evolution, I get > evolution: error while loading shared libraries: libical.so.1: cannot open > shared object file: No such file or directory Oh, I see, once they moved to version 1.0, they bumped the soname version (expected), thus the binary built against newer libical cannot find it. I do not think they changed the API significantly (at all), thus I'd try to create a copy of missing files in /usr/lib (or /usr/lib64) with .0 name suffix.
When I do this, I get a segmentation fault as soon as I try to open the calendar in evolution.
Oh, that's bad, so they changed the API in some way. That means there is no way of trying older version of libical.
I found the commit that is causing this problem. The whole part to get builtin timezone was rewritten and changed the behavior. I already opened a bug against libical[0] and provided all necessary information to them. Waiting some answer, at least an ACK that it's a regression and not the desired behavior since the beginning. [0]: https://sourceforge.net/p/freeassociation/bugs/95/
Great Fabiano, thanks. I can confirm that your patch fixes the problem.
Can you please let me know how to apply this patch? Sorry I am new to this. thanks
(In reply to comment #15) > Can you please let me know how to apply this patch? Sorry I am new to this. > thanks Hey Nick, You sent me a personal e-mail, which one I already replied. Basically, did you realize this patch is for libical and not for evolution-ews? Anyway, just clone/checkout the libical repo[1] and do: ffidenci@srv ~/src/upstream/libical $ patch -p1 < 0001-Revert-Fix-TZ-rules-make-the-VTIMEZONE-specifier-an-.patch [1]: http://sourceforge.net/p/freeassociation/code/HEAD/tree/trunk/libical/
*** Bug 728582 has been marked as a duplicate of this bug. ***
I'm closing this, there is not much we can do with this in evolution(-ews), because the problem lies in libical.