Hide Forgot
Description of problem: Exchange calendar events created with another device (smartphone, Outlook for Mac, tablet, etc), all show up with their UTC time in Evolution. Exchange calendar events created in Evolution however, correctly show up as local time in Evolution. Furthermore, if I take an Exchange calendar event created on another device, open it in Evolution, and change the time from the displayed UTC time, to local time (an 8 hour swing), and then save it, it not only corrects the time showed in Evolution, but it doesn't affect the time shown on other devices (just as if I had created the event in Evolution to begin with). Version-Release number of selected component (if applicable): evolution-ews-3.6.4-1.fc18.x86_64 evolution-3.6.4-3.fc18.x86_64 evolution-data-server-3.6.4-4.fc18.x86_64 How reproducible: Always Steps to Reproduce: 1. Create an Exchange calendar event with a device other than Evolution 2. View the calendar event in Evolution 3. Actual results: Time is shown in UTC time Expected results: Time should be shown in local time Additional info: In Evolution "Preferences"-> "Calendar & Tasks"-> "General" -> "Time", I've changed the time zone from "use system time" (it did have the correct time zone displayed under system time, BTW), to unchecking that box, and manually setting the timezone, to no avail. The time shows up as UTC regardless. I'm running KDE as my desktop. My TZ is PST. I've had this problem for a while (at least since Fedora 17), but haven't gotten around to reporting it until now.
Oh, and we're running Exchange 2010.
Another update. And this is a strange twist: Apparently my most recent switch from "system time" to manually setting the timezone to PST took.... but only for group meetings organized by other people. Events created by me on other devices are still UTC.
Another update: Exchange events created by me - ones that I've previously corrected as outlined in the initial bug report, revert to UTC time every time I switch between "system time", and manually setting it to PST (which of course it shouldn't do because it is the same timezone). This causes me to have to open each of them and resave them as local time (of course specifying the timezone when I do so).
After playing with this some more, the issue appears to be that local time (PST in my case) isn't automatically assumed/assigned for all calendar events. The issue in Comment #3, seems to be triggered by the fact that the timezone specified in calendar events is dropped when the timezone is changed in Evolution (even though it technically isn't changing - only whether it is sourced from the system or being manually specified).
Thanks for a bug report. I'm sorry, but 3.6.x is way too old, it'll be better if you could retest with more recent version, like 3.10.1/3.10.2, which is part of Fedora 20 Beta (like installing a virtual machine with Fedora 20 Beta and test it there, rather than reinstall whole system immediately). There were done many fixes and improvements in evolution packages, including evolution-ews, and my testing with it doesn't exhibit the issue you described.
Before I spun up Fedora 20 on a VM (per your request), I went ahead and fired up Evolution on my home workstation, which is running Fedora 19. I didn't see the problem there... so it appears the problem is actually fixed in the most recent 3.8.5 version? At that point, I upgraded my work workstation (using fedup) - the one mentioned in this bug report - to Fedora 19, but the problem remained. Evolution versions: evolution-data-server-3.8.5-6.fc19.x86_64 evolution-3.8.5-2.fc19.x86_64 evolution-ews-3.8.5-3.fc19.x86_64 Comparing Evolution rpms on my home workstation showed identical versions and installed rpms. Additionally, the settings visible in the Evolution GUI were identical, so where is the problem originating from? After thinking about this a little bit I realized that my work workstation has been installed as Fedora for several years and has seen several OS and Evolution upgrades. I also had to change Evolution from using the evolution-mapi plugin to evolution-ews when we upgraded our Exchange server. After I thought about this some more, I figured that there has to be some legacy setting that Evolution is reading from somewhere that is causing this issue. So I fired up a terminal and nuked every evolution directory that I could find: rm -rf .local/share/evolution/ rm -rf .gconf/apps/evolution/ rm -rf .cache/evolution/ rm -rf .config/evolution/ pkill evolution #kill any background processes From here I went ahead and fired up evolution again, and setup my Exchange account in Evolution once again. Now my calendar times are correct!!! So feel free to close this bug...? Unfortunately I don't know what legacy setting was causing this issue, but it may be advisable for anyone else that comes across this bug, that is having this issue, to clear out any old settings as I did above. Also, as an aside, regarding 3.6.x, I haven't seen the software stack lined up for RHEL 7, but what version of Evolution is shipping with RHEL 7? I'd guess it would be based (at least partly) on Fedora 18?
(In reply to Chad Feller from comment #6) > Before I spun up Fedora 20 on a VM (per your request), I went ahead and > fired up Evolution on my home workstation, which is running Fedora 19. I > didn't see the problem there... so it appears the problem is actually fixed > in the most recent 3.8.5 version? I suggested Fedora 20 to get the most recent, upstream supported version 3.10.x. > ... > From here I went ahead and fired up evolution again, and setup my Exchange > account in Evolution once again. > > Now my calendar times are correct!!! Hmm, it seems like ~/.cache/evolution/calendar/<ews calendar uid>/ had stored some odd timezone and used it to convert the time from the server to/from for evolution. At least from your description. Do you have a backup of the deleted folders? Maybe it would help to find out what exactly broke there, to fix migration in the future.
I do have backups - do you want something specific, or whole files/directories? (Just so I don't have to spend more time stripping out potentially sensitive data than I would otherwise need to.)
Search for keys.xml files in ~/.cache/evolution/calendar/<ews calendar uid>/ , one for EWS might be under subfolders which is a long base64 like string, so it's ~/.cache/evolution/calendar/<ews calendar uid>/AAMkAGF....7D82/keys.xml it contains two keys for me, "default-zone" and "sync-state". The default zone is UTC for me. Might it be that you have a different default zone?
I have a "default-zone" and "sync-state". The default zone (in both the backup and the current version) is UTC: <object uid="default-zone">UTC</object>
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
(In reply to Chad Feller from comment #10) > I have a "default-zone" and "sync-state". The default zone (in both the > backup and the current version) is UTC: > > <object uid="default-zone">UTC</object> Then it should surely work properly, unless I missed some change between your version and mine, which eventually could fix the issue. I use the development version currently, but it might be the same as 3.10.x, thus the version shipped with Fedora 20.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.