GNOME Bugzilla – Bug 665250
Map GMT Standard Time to Europe/Dublin
Last modified: 2011-12-19 15:46:03 UTC
Evolution 3.0.3 with evolution-mapi 3.0.3-2 on Fedora 15. I have a repeating calendar event at 930am every Thursday (US eastern time) that was created a long time ago by someone in England (GMT; it's 230pm their time). As of the Nov 10 occurrence of the event, it is showing up at 830am on my calendar. This is clearly wrong. I believe because it worked correctly (sorta, see below) on Nov 3, and incorrectly on Nov 10, it was probably triggered by the end of US daylight savings time on Nov 6. A separate problem, which may not be a bug, is that the event didn't change time on Nov 3, which falls in between when European Summer Time ends (Oct 30) and when US daylight savings time ends (Nov 6). During this week, the time zone offset between England and the Eastern US changes from its normal 5 hours to only 4 hours. The opposite of course happens in the spring. I think the calendar event _should_ move in this case, since I assume it is controlled by the time zone of the creator of the event.
Thanks for a bug report. I agree that this is caused by the timezone the event is shown and set in. The simplest test would be to login to your server's web (OWA) interface, and see how it's shown there, supposing you've set there the same timezone for the calendar as you have in evolution. Then in evolution, you can also edit the event and choose View->Timezone, which will show you which timezone the event is in. You may also check what timezone is set in evolution itself, under Edit->preferences->Calendar and Tasks. Time shifts are computed by libical, and it takes it from the system, from /usr/share/zoneinfo timezone definitions.
Every instance after Nov 6 shows in OWA and Outlook at the correct time (930am), but shows at 830am in Evolution. The event shows at 1030am in OWA and Outlook on Nov 3, whereas it shows at 930am in Evolution. Outlook is correct here. Evolution's TZ is "America/New_York", as I alluded to before. The event's TZ is UTC (in both Evolution and Outlook). This seems odd to me, since UTC does not have DST. I wonder if Microsoft's definition of UTC is actually GMT, and thus includes DST? It does mention in Outlook the cities of Dublin, Edinburgh, Lisbon, London as the description of UTC. It seems to me that one of two things is going on here. Firstly, it might be translating incorrectly between Microsoft's idea of UTC and real UTC, which would probably explain everything. There's also the possibility that Evolution is calculating the local time for every event in the series based on the TZ offset on the date the series was created. It should instead be re-calculating the TZ offset on every instance of the series. I haven't actually looked at the code to confirm this is what is happening, it's just a hunch I have from the observed behavior. Thanks!
Thanks for the update, that's it Dublin, ... is not a real UTC (as evolution treats it), but exchange server returns "GMT Standard Time" where Europe/Dublin is the correct timezone for Evolution.
Created attachment 203856 [details] [review] ema patch for evolution-mapi; Changing the mapping for timezones. It's in external files, thus you can patch it too. They are located in /usr/share/evolution-data-server-3.0/mapi/. To recreate components, you need to download them again, which can be done by deleting the local cache, which is stored in ~/.cache/evolution/calendar/mapi* (or somewhere there, I'm not sure with 3.0.x), or edit the calendar.ics file in the folder and delete only those affected events (it's only for a case if you've too large calendar, but otherwise the complete delete of the cache folder will work too). Note all the information is stored on a server, thus no issue to delete the local cache.
Created commit cf1bd98 in ema master (3.3.3+) Created commit 97d3b67 in ema gnome-3-2 (3.2.3+)
I applied the patch and cleared my cache per your instructions, and I'm happy to report the issue is now resolved! Thank you very much for your swift attention to this issue.