GNOME Bugzilla – Bug 332911
Exchange calendar item display disrespects timezone
Last modified: 2013-09-13 00:51:39 UTC
Please describe the problem: Outlook has a meeting listed for 11:15AM MST. Evolution shows this meeting at 1:15PM MST. I dig down into personal/subfolders/Calendar/cache.ics and find the following: BEGIN:VEVENT DTSTAMP:20060228T152850Z DTSTART;TZID=(GMT-05.00) Eastern Time (US & Canada):20060302T131500 SUMMARY:Updated: Team Lunch So it appears that for whatever reason, Exchange or somebody decided to use EST for this meeting start time, but Evolution didn't apply the timezone correction. Other key points: I don't have TZ set, but I do have the timezone set to Denver in the preferences. Most meetings do show up where they're supposed to. Steps to reproduce: 1. Set up a meeting such that it has another timezone 2. 3. Actual results: Timezone correction not applied. Expected results: Get the timezone right. Does this happen every time? It does for certain meetings. Other information:
This is on garnome-2.13.91.
my guess: i really doubt that the time zone identifier "(GMT-05.00) Eastern Time (US & Canada):20060302T131500" can be recognized properly by evolution. evolution uses the public-domain Olson database, and evolution cannot parse any kind of strange string to find out that information - guess we need artificial intelligence to do that. ;-) sadly, rfc2445 does not cover the time zone identifier format. so, which application creates "(GMT-05.00) Eastern Time (US & Canada)" time zone identifiers? outlook? which outlook version did this? how did you import that into evolution? thanks in advance.
This meeting was generated by Outlook 2003. I'm trying to use evolution-exchange to pull data from our corporate exchange server, so I don't know if the TZ came from OL2003 or Exchange itself.
Created attachment 61695 [details] another example with unrecognized TZID (?) I have a similar problem as Doug: according to Outlook the meeting starts at 17:00 (5pm) CET, which is consistent with the 8:00am Pacific Time of the person who created the meeting invitation with Outlook. Evolution shows that meeting at 16:00 CET in my calender. I tried with both a local calender and an Exchange calender. Luckily I didn't miss the meeting, I just tried to dial in early. Still, this is a real problem. My Evolution is 2.6.0, compiled with garnome 2.14.0. TZ is unset, system time zone is CET, Evolution is set to "Europe/Berlin". Other meetings and the system time are displayed correctly be Evolution. Andre, if you can give me a pointer into the source code I could try to come up with a patch.
Interesting: the alarm came up for my example at the right time (a quarter before 17:00 CET). When looking at the meeting invitation with the ITIP formatter, the time was also correctly displayed as 17:00 till 18:00. So there seems to be code in Evolution which parses the meeting correctly, it's just the calender itself which doesn't.
Guess what I found earlier in the cache.ics: BEGIN:VTIMEZONE TZID:(GMT-05.00) Eastern Time (US & Canada) X-MICROSOFT-CDO-TZID:10 BEGIN:STANDARD DTSTART:16010101T020000 TZOFFSETFROM:-0400 TZOFFSETTO:-0500 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10 END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T020000 TZOFFSETFROM:-0500 TZOFFSETTO:-0400 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=4 END:DAYLIGHT END:VTIMEZONE So Exchange does define its own timezones. Apparently Evo is not picking these up and dumping them into the databse.
Created attachment 61719 [details] Sample cache.ics I'm attaching a cut-down cache.ics that I think illustrates this. It's got all of the VTIMEZONEs in it and one VEVENT with the Eastern TZ in it.
I found that it is icaltimezone_get_builtin_timezone_from_tzid() in icaltimezone.c of the evolution-data-server where time zones not in the standard /softwarestudio.org/ format are lost. This is clearly not right and renders Evolution incompatible with for example Outlook. I also found TZIDs in my calender of the format "GMT +0100 (Standard) / GMT +0200 (Daylight)" although I cannot say where those came from. Either way, attached is a patch which extends icaltimezone.c so that Outlook TZIDs are recognized and mapped to Evolutions concept of locations where possible. This is done via the GMT offset because that can be extracted relatively easily from those unknown TZIDs. I created a template .ics file and then with sed manipulated the GMT offset. Then I imported them all into my local calender and behold, all which have a corresponding Evolution location are now displayed correctly :-) See the timezone.tar.gz for the test data. Note however that the 8:00 am is actually in CET (=GMT +01), not GMT as it says - I mislabeled it, but then didn't want to go through the whole import again. Not supported are these rather exotic time zones: -2 Mid-Atlantic -12 International Date Line West +13 Nuku'alofa (in Tonga) What steps are necessary to get this into the upcoming update of Evolution? Please note that it probably affects all steps where Evolution needs to interprete the time zone. I suspect that this might also explain the error reports about time zones being lost when copying between calenders (don't rememeber the issue number). I'd like to suggest to raise the priority of this issue. At least for me it makes the Evolution calender completely unreliable, because I work a lot with international meeting invitations.
Created attachment 61772 [details] [review] fuzzy guessing of foreign time zones
Created attachment 61773 [details] test cases with different GMT offsets covering the whole range
Looking at the VTIMEZONE entries in the Exchange cache.ics, we have all the info we need. It appears to me that the exchange backend is just not associating the timezone entries with the VEVENTs the way it should. I suspect the exchange code is guilty here, but I haven't untangled it yet...
The same problem is mentioned in https://launchpad.net/distros/ubuntu/+source/evolution-exchange/+bug/33534 as well: "Any appointments that are created within Evo are fine, only events created into an Exchange-Connector Calendar by Evo based on invites from Outlook 2003/Exchange suffer from this anachronicity."
Doug wrote: > Looking at the VTIMEZONE entries in the Exchange cache.ics, we have all the > info we need. Does that refer to my patch? Can you try whether it works for you? > It appears to me that the exchange backend is just not > associating the timezone entries with the VEVENTs the way it should. > I suspect the exchange code is guilty here, but I haven't untangled it yet... It also happens when importing an Outlook email meeting invitation into a local calender (that's in fact what I have been testing with). Fixing it in the exchange connector code would not cover all cases where this goes wrong. I think it is better to teach libical how to deal with these TZIDs.
I tried the patch and it does work. My concern was just that we have the appropriate VTIMEZONE data that we need. The "Right" fix would be to use it because then there wouldn't be problems with things like goofy timezones and areas that don't go on DST, etc.
Doug wrote: > I tried the patch and it does work. My concern was just that we have the > appropriate VTIMEZONE data that we need. The "Right" fix would be to use it > because then there wouldn't be problems with things like goofy timezones and > areas that don't go on DST, etc. I see what you mean now. However, this will probably require a lot more work and affect more than just one source file (it's certainly more work than I could handle). My advice would be to fix the immediate problem in Gnome 2.14.1 with the patch that I have provided (or something like it; one possible improvement would be to have a more fine-grained mapping for multiple locations with the same GMT offset) and then create another feature request in Bugzilla about adding support for Outlook's timezone definitions.
chen, can you please take a look at this? a patch is available here. we're getting more and more dups on this. targetting to 2.6.
...also see bug 339826, bug 339829, bug 337201, bug 336367 and bug 326011. they could be/are related.
This is not just a problem with Evolution <-> Outlook, it also doesn't work correctly with Apple iCal (example TZID:US/Eastern and TZNAME: EST). So this patch will just deal with Outlook, and then another hack will have to be made for iCal, then one for ...... As with the Outlook VEVENT, iCal includes a proper VTIMEZONE definition, as should all clients. So the proper fix would be to use the VTIMEZONE definition, wouldn't it? Then everything is fixed, not just Outlook.
Lonnie wrote: > As with the Outlook VEVENT, iCal includes a proper VTIMEZONE definition, as > should all clients. So the proper fix would be to use the VTIMEZONE > definition, wouldn't it? Then everything is fixed, not just Outlook. I agree, the patch that I proposed was only a stop-gap measure which would have helped to mitigate the problem in 2.6.1 (in fact, I currently use it in my self-compiled 2.6.1), but it is too late for that now and it would be better to add proper handling of VTIMEZONE definitions. From looking at the ical/ecal API it is not obvious to me how this could be done, though. Is there a central database of timezones which is shared by the various processes and that can be updated permanently? I know there is the Olson database, but I don't know whether it is shared and whether it can be extended. As far as I can tell Evolution calendars only store the VEVENT ical component and the related timezones must be stored in such an extra database.
Patrick wrote: > As far as I can tell Evolution calendars only store the VEVENT ical component > and the related timezones must be stored in such an extra database. I don't know the Evolution code base well, so I have no idea what this entails, but..... what if Evolution saved the VTIMEZONE information in the calendar.ics file (even for events it created itself). Then it would be available to be parsed by the calendar display code. This would also fix issues with the iCal created webcals in different timezones that I subscribe to showing at the wrong (non-timezone adjusted) time. (These webcals contain VTIMEZONE info, so the code that parses that info in the local calendars would also work on remote calendars -- although Rodrigo had fixed this back in 2.2 using a different method, it's been broken since sometime in 2.3)
Hi patrick, dough, I have made a patch to fix the issue some time back, http://mail.gnome.org/archives/evolution-patches/2006-April/msg00048.html. Could you please apply this patch.
The above patch will get the timezone from the exchange backend if its not present in ical builtin timezone. we still have some issues with DST handling. This must be fixed in libical.
Maybe I'm missing something in the patch. Will it use the VTIMEZONE information in the .ics file, if it is present? Doug (the original reporter) stated that his local cache.ics file had that information in it as delivered from the exchange server. Using the VTIMEZONE data would also solve the DST issue, since it has the DST information in it.... plus it would fix the exact same timezone handling problem that exists with webcals. Or does this just fix exchange calendars and leave the rest still broken?
The function e_cal_get_timezone would get the timezone from the respective backend. The backend can be exchange, file (local), webcal or groupwise. I will be committing the patch today to cvs HEAD and gnome-2-14 branch.
*** Bug 341360 has been marked as a duplicate of this bug. ***
*** Bug 315235 has been marked as a duplicate of this bug. ***
chen, news on this? (bug 307468 is another bug to be added to my list at comment 17)
ah, okay, just saw the changelog.... "partially fixed". okay. http://cvs.gnome.org/bonsai/cvsquery.cgi?branch=&dir=evolution&who=pchen&date=explicit&mindate=2006-05-11%2005:29&maxdate=2006-05-11%2005:31
Can the title be changed to reflect that this same issue happens in GroupWise? You merged my bug over to this one, so the two are obviously related. We book meetings a year in advance and items are ending up in the wrong times after daylight savings time.
(In reply to comment #29) > Can the title be changed to reflect that this same issue happens in GroupWise? > You merged my bug over to this one, so the two are obviously related. > > We book meetings a year in advance and items are ending up in the wrong times > after daylight savings time. > What is the timezone which your using ?
We are in eastern time zone, but I suspect this bug is happening to everyone. October 29th is the time change date, so I booked a meeting starting a few days before and then recurring after that date. In the shot I will attach, you can see the days before the meeting is for 8am, and then after that date they flipped to 7am. They were sent as all being 8am.
Created attachment 66832 [details] Recur meeting sent over DST change, before they are ok, after they are 1 hour off. Meetings marked with green are ok, red meetings are bad.
*** Bug 344226 has been marked as a duplicate of this bug. ***
Chenthill wrote: > Hi patrick, dough, > I have made a patch to fix the issue some time back, > http://mail.gnome.org/archives/evolution-patches/2006-April/msg00048.html. > Could you please apply this patch. I didn't have time to try out the patch, but I compiled Evolution 2.16.2 (which contains the patch) when Garnome 2.14.2 became available: the problem is gone as far as I can tell. Thanks! I'm not sure which cases are not addressed by Chenthill's partial fix, though. Chenthill probably knows better. BTW, I second the suggestion to change the title of this issue. It definetely isn't an Exchange specific problem.
Pardon Spam, add harish to CC
Harish- Looks like some possible patches are available for this issue. It's happening it seems to both Exchange and GroupWise backends. We are getting closer and closer to the time change and more appointments are crossing that date and getting set incorrectly. Our users are having to book pre and then post time change recurring meetings as separate events. If this patch is close or works, it knocks out one of our SRs submitted to Novell.
I seem to be suffering from this. An additional symptom nobody has mentioned above: - When I look at the invitation in my email, it displays the time _correctly_ in my local time zone. (MST, invitation from EST). However it shows up on the calendar view with the wrong time. (2 hours off). I hope this is consistent with the fixes & patches... Also, it seems fairly feasible to hope that the upcoming patch will transparently fix all of the meeting invitations I've accepted recently, so I don't have to delete then re-accept everything?
harmonizing target milestones, sorry for the noise. (2.6.x -> 2.6)
*** Bug 337201 has been marked as a duplicate of this bug. ***
Created attachment 68242 [details] [review] This adds support for users to optionally use the daylight savings time.
Created attachment 68243 [details] [review] patch for EDS
Created attachment 68285 [details] [review] Updated eds patch
Created attachment 68286 [details] [review] Updated EDS patch, handles the utc timezone properly for contacts backend
Created attachment 68288 [details] [review] EDS patch, Mark the virtual functio ndefault_timezone in sync backend as deprecated.
I installed this experimental patch from the new RPMs on SLED 10 and checked the box to use the Daylight Savings time and it did the same thing. A recurring meeting that goes over the change move back 1 hour starting with the first date of the change. Marked in the shot, the green entries are correct, and the red entries are 1 hour too early.
Created attachment 68493 [details] green are good, red are bad
The movement of the meeting by 1 hour is due to the daylight savings time. The option should not be set if you do not want the recurring meetings to change by 1 hour.
*** Bug 342735 has been marked as a duplicate of this bug. ***
Sorry for all of the spam to the list. We are testing the patches that will fix this issue. Ok, unchecked the box and sent appointments and with the box unchecked it's generating even worse meetings. What happens is that they display ok on the UI, but they show up in your Mailbox incorrectly: 1) It shows up in the wrong day. The meeting sent for today showed up in the Mailbox folder for the previous day (see shot). 2) The meetings are marked as being 12:00AM to 12:00AM (see shot). Shot shows bad sections in red, from meeting sent for today.
Created attachment 68559 [details] meeting appears in wrong place in Inbox, wrong times in preview pane, marked in red
More email, sorry all: But as quickly as I was typing Chen was getting me a patch for EDS and it's working now. Meetings sent over the weekend of DST that recur all go to the right times. I will continue to test, but this code should be merged in ASAP.
Fix committed to cvs HEAD.
Reopen: This patch is making the Marcus Baines line display the wrong time. It's 1 hour behind where it should be. That will make the calendar daemon I think not give you an alarm at the right time. I can't reopen this one, can someone do that please?
reopening on behalf of dave.
Dave, please have the setting "Adjust for daylight savings time" enabled. Am reopening the bug 341360 as it needs a server side fix, have filed a defect on the server end https://bugzilla.novell.com/show_bug.cgi?id=191807. The utc times generated at the server end does not adjust for the daylight savings changes. The Marcus banes line displays the time without the daylight savings changes. Am closing this bug as the appointments display in the right timezones sent from exchange.
*** Bug 347948 has been marked as a duplicate of this bug. ***
*** Bug 350810 has been marked as a duplicate of this bug. ***