Sorry, I had the 5-hour offset stuck in my mind.  The Expected Results should be that the meeting is accepted for 3:00 PM.

Thanks for a bug report. I see you mentioned Microsoft Exchange (MAPI), does it mean that you see this issue in a mailbox you have accessed by evolution-mapi plugin, thus it's type in account preferences shows "Exchange MAPI"?

I've more questions on timezones:
a) do you use same timezone as the sender, especially the one set in 
   Edit->Preferences->Calendar and Tasks->Timezones
   because the invitation plugin shows times in your local timezone,
   not in the timezone being set in the event itself
b) the same can apply to calendar view
c) when you edit the accepted event in your calendar, and select menu
   View->Timezone, is there shown the UTC

I'm asking these basic questions, because I do not have access to Microsoft-Entourage for testing. The reason for using UTC might be that the timezone being set on the event times is not recognized by evolution-mapi, thus it fallbacks to UTC.

Yes, I am using evolution-mapi for Exchange MAPI.  My time-zone settings are indeed the same as the three individuals from whom I have received invitations and who use Entourage on their Macs.  My settings are set as you suggested above for US/Eastern, and the meeting invitations display as if they are 5 hour later (one such meeting would be set for 8:00 PM this evening, for instance, if I did accept it in Evolution.)  That offset is what I base the suggestion that the Entourage-generated invitations are possibly tagged in a way that Evolution displays the meeting time incorrectly.

I could, I suppose, accept the meeting and edit it in Evolution Calendar.  But I find it better from this user's experience, to accept the meeting from Outlook Web Access.

(In reply to comment #3)
> I could, I suppose, accept the meeting and edit it in Evolution Calendar.  But
> I find it better from this user's experience, to accept the meeting from
> Outlook Web Access.

After accepting you've it added into your calendar, which should be visible from evolution afterwards. I just recalled one other option, if you show message source (Ctrl+U) of the message invitation in evolution, then there is shown the event as text. If you search it for TZID string, then you might either find it and see what timezone is used, or it will be missing. In that case search for DTSTART, please, and paste here its whole line.

I do not think I'm able to investigate this otherwise than making certain changes into evolution-mapi, to dump properties recognized on the object and check what is stored on the server.

If you are willing to run a test package, which will dump MAPI properties being stored on the message, then I have a test package built [1]. You can install it with something like
  $ rpm -Uvh package-name
and if anything will go wrong then you can revert back to the standard package:
  $ yum downgrade evolution-mapi

Just run evolution from console like this:
  $ evolution &>log.txt
and the evolution-mapi code will dump each message it downloads to the file (it'll be rather long list of MAPI properties with their values).

The only issue is that messages are downloaded only once, when you open message which is already in a cache then it is not downloaded again. Thus look at
  ~/.local/share/evolution/mail/<mapi-account-id>/folders/...
where is stored mail cache of your MAPI account. The three dots '...' are meant as a folder structure similar to that shown in a folder tree in a mailer view. For me it's like
  ~/.local/share/evolution/mail/<mapi-account-id>/folders/Mailbox - Milan Crha/Inbox/cache/XX/<message-id>
for messages in my MAPI Inbox. Finding the offending message to delete, can be tricky. Maybe try by date.

When you delete the message from the cache, and start evolution afterwards, then selecting the message may write debug information into the log. Feel free to send the log only to me, to avoid sharing it in public, because it contains basically anything related to message itself. Only make sure you'll write bug number into the subject, otherwise I may overlook it in my "maybe-spam" folder. Thanks in advance.

[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=3768152

I am sorry.  I ran into a critical time in our development cycle and I had to put Evolution to the side for the last couple weeks.  Now that I have some time to get back to it, I see the package seems to be closed, or at least I cannot get to a download link that works (unless I am missing something...) So I will investigate using your earlier reply regarding TZID and DSTART values.

Created attachment 564678 [details]
Duplicated appointment

This is a screenshot of how the example meeting is displayed in Evolution.  I believe the meeting was set and accepted at one time, and then updated with more information a second time.  The "two" appointments are indeed the same meeting, and they are both displayed at the correct time.  However, one shows UTC and the other New York/EST as the time zone.

Sorry, I had started some earlier comments which were lost when I attached the image.  A Mac user has now arrived, so I can get some real data.

Created attachment 564697 [details]
Screenshot of a new invite from an Entourage user

This meeting invitation shows the conflicting information: a meeting for 10AM which indicates a Start Time of 3PM.  The source shows the correct time in the description (10:00 AM), but the DSTART is incorrect (T1500).  And there is no TZID.  Here is the source of the invitation:


X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: from 10.68.221.27 ([10.68.221.27]) by exchange.<snip>
 ([10.68.91.21]) with Microsoft Exchange Server HTTP-DAV ; Tue, 21 Feb 2012
 14:24:15 +0000
MIME-Version: 1.0
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 21 Feb 2012 09:24:16 -0500
X-MS-Has-Attach: 
X-MS-TNEF-Correlator:
 <BBB9F0110BBE664AA1BD301B11473BD2011D8014@exchange.<snip>>
Thread-Topic: Bogus meeting
Thread-Index: AczwpH2iPsF0Frttw0uWqaa1wS0huQ==
To: "Jay Burrill" <jburrill@<snip>>
Content-class: urn:content-classes:calendarmessage
Subject: Bogus meeting
Reply-To: Lee<snip>
From: Lee<snip>
Message-ID: <BBB9F0110BBE664AA1BD301B11473BD2011D8014@exchange.<snip>>
Content-Type: multipart/mixed; boundary="=-Nstn2yA/ewvA/iQbf/wx"
X-Evolution-Source: 1328191387.4635.0@LPUX-DBNFQ1.<snip>


--=-Nstn2yA/ewvA/iQbf/wx
Content-Transfer-Encoding: 8bit
Content-Type: text/calendar

BEGIN:VCALENDAR
CALSCALE:GREGORIAN
PRODID:-//Ximian//NONSGML Evolution Calendar//EN
VERSION:2.0
METHOD:REQUEST
BEGIN:VEVENT
UID:B27F4C0100000045
DTSTAMP:20120221T142415Z
CREATED:20120221T142427Z
LAST-MODIFIED:20120221T142419Z
SUMMARY:Bogus meeting
DESCRIPTION:10:00 AM - 10:30 AM February 21\, 2012\r\n\r\n\r\n\r\n
X-EVOLUTION-MAPI-OWNER-APPT-ID:0000000065B4899F
DTSTART:20120221T150000
DTEND:20120221T153000
TRANSP:TRANSPARENT
ORGANIZER;CN=Lee<snip>:MAILTO:lfrancis@<snip>
CLASS:PUBLIC
BEGIN:VALARM
X-EVOLUTION-ALARM-UID:
 20120221T142427Z-4575-1000-2042-20@LPUX-DBNFQ1.<snip>
ACTION:DISPLAY
TRIGGER;VALUE=DURATION;RELATED=START:-PT15M
END:VALARM
END:VEVENT
END:VCALENDAR

--=-Nstn2yA/ewvA/iQbf/wx--

Interestingly enough, this meeting is now logged correctly on my calendar, at 10AM (and I have to finish this post so as not to be late ;-)), despite the conflicting information within the invite.  I will have to look to other Entourage user invites which had been problematic in earlier invitations.  One such is my manager, who will have several invitations for me in coming days.  Perhaps this is just an issue with the version of Entourage?? (Above User-Agent: Microsoft-Entourage/12.32.0.111121)

regarding your other investigating strategies, deleting cache records to download old invitations, I unfortunately am so far unsuccessful as I went away from using Evolution with project demands.  I will continue to look as time permits...  Of course, if I receive another invitation from other Entourage users, I will be sure to look at the new information.

I have jsut received a meeting cancellation, not an invite.  It too showed the time offset in the UI.  And the source shows that it has a HTTP-DAV date in the future, 15:19:17.  This is the problematic sender, who uses a different version of Entourage, although I do not see here any indication of its version.  I will supply more data as it comes...

=====

X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: from 10.68.10.11 ([10.68.10.11]) by exchange.<snip>
 ([10.68.91.21]) via Exchange Front-End Server webmail.<snip>
 ([10.68.91.31]) with Microsoft Exchange Server HTTP-DAV ; Tue, 21 Feb 2012
 15:19:17 +0000
MIME-Version: 1.0
Date: Tue, 21 Feb 2012 10:19:17 -0500
X-MS-Has-Attach: 
X-MS-TNEF-Correlator:
 <8762826C21474740BDBFEED2D9AD2607064E076F@exchange.<snip>>
Thread-Topic: Subscriptions IT-2 Dev Status
Thread-Index: AczwrC1OdlQIPO5sRmGbjmuMlgwNeg==
To: "Jay Burrill" <jburrill@<snip>>, <snip>
Cc: <snip>
Content-class: urn:content-classes:calendarmessage
Subject: Subscriptions IT-2 Dev Status
Reply-To: Ron<snip>
From: Ron<snip>
Message-ID: <8762826C21474740BDBFEED2D9AD2607064E076F@exchange.<snip>>
Content-Type: multipart/mixed; boundary="=-En+VlcI4BlQRa8Fl8aE0"
X-Evolution-Source: 1328191387.4635.0@LPUX-DBNFQ1.<snip>


--=-En+VlcI4BlQRa8Fl8aE0
Content-Transfer-Encoding: 8bit
Content-Type: text/calendar

BEGIN:VCALENDAR
CALSCALE:GREGORIAN
PRODID:-//Ximian//NONSGML Evolution Calendar//EN
VERSION:2.0
METHOD:CANCEL
BEGIN:VEVENT
UID:B47F4C0100000045
DTSTAMP:20120221T151917Z
CREATED:20120221T151947Z
LAST-MODIFIED:20120221T151918Z
SUMMARY:Subscriptions IT-2 Dev Status
DESCRIPTION:IT-2 ends 17-Feb.  \r\n\r\nHere are the open tickets:
 \r\n\r\nhttp:
 //jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=component+%3D+Subscr
 iptions+AND+status+%21%3D+Resolved+AND+status+%21%3D+Closed+AND+%28affecte
 dVersion+%3D+%22SUBS+IT-2%22+or+affectedVersion%3D%22SUBS+IT-1%22%29+ORDER
 +BY+assignee+ASC%2C+key+DESC\r\n\r\n
X-EVOLUTION-MAPI-OWNER-APPT-ID:00000000FFFFFFFF
LOCATION:Plum
DTSTART:20120221T153000
DTEND:20120221T160000
TRANSP:TRANSPARENT
ORGANIZER;CN=Ron<snip>:MAILTO:r<snip>
CLASS:PUBLIC
END:VEVENT
END:VCALENDAR

--=-En+VlcI4BlQRa8Fl8aE0--

Created attachment 564720 [details]
Cancellation message with warnings

I should also mention, that this cancellation message also reads that 1) the meeting conflicts with another meeting in the calendar (I guess the entry that is being deleted?); and 2) it is unable to find this meeting in my calendar.  Unfortunately the source of the cancellation message above does not include these warnings that are displayed in the UI; a screenshot is attached.

Thanks for the update. I see from the vCalendar event "sources", that evolution-mapi translated DTSART and DTEND as in a floating time, which means they are set without timezone, with a meaning that this is your local time, whichever timezone you are currently in.

The reason for event not being recognized and being filled into the calendar twice might be that the event's UID doesn't match. One of those events could be added by the server itself, while the other could be added by Evolution, when you accepted it. Seeing source properties, as provided by the server, would be helpful.

I just realized there is no need for a special build, we can get basically the same output if you try things from comment #5 with evolution being run as this:
   $ CAMEL_DEBUG=mapi:folder evolution &>log.txt

While testing the command I realized that it does the same for me, times are set as floating, even the invitation object contains timezone information. This is with 3.2.3-1. Current development version 3.3.90 sets timezone to UTC, which is correct, because the times in used properties are in UTC, though it still can do better, because the timezone set on the invitation object can be different.

I'm sorry for not testing this on my side first, I was pretty sure this timezone thing on invitations was working correctly. I'll check what I can do for 3.2.x and for 3.3.x. Thanks for your help with this.

This build [1] changes generation of meeting invitations, to use either timezone known from the object, or UTC, instead of floating time. One usually has the time defined as UTC, but that's the correct time, thus when converting to user's time zone (set in evolution), the time is shown correctly.

I would like to ask you to test it, the only thing is to remove your local mail cache, thus the test messages are reloaded. You can do that as I wrote in the second half of comment #5. If it'll work then I'll publish it an update for Fedora 16. Thanks in advance.

[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=3809932

I apologize for my naivete...  But how do I pull down this build in 
<a href="show_bug.cgi?id=787279#c15">comment #15</a>.  I can clear my entire cache and do this, since, I don't currently have a recent invitation cached for the particular user of Entourage that seems to be at issue to enable me to find the particular cache entry to delete.  But I do not mind doing this to see if I can help.

Sorry. Think I found it from links to the taskID=3809933...

Created attachment 566076 [details]
ZIP of log.txt from recent Evolution activity

I apologize for my lack of activity here.  I have been on a short holiday, and was only able to access email on occasion, via VPN.  Our Juniper VPN does not have Linux support, so I was left to boot to Windoze for domain access and to use Outlook over that time (more on this later).  I have finally had a meeting invite or two which were from a sender who historically had shown the mismatched meeting invitation dates.  However, it seems that after installing the RPM from the last link you provided, the meeting invitations display with the correct time in the message, and are set in the calendar at the correct time, as well.  I have attached the log.txt file for this morning with two such meeting acceptances, and some history (although I did not search for other meetings - which I do not believe are present.)

My calendar does have duplicate meetings for the two acceptances that I have today.  You may have insight into this, I do not know.  But I wonder if in this particular instance, it is in part due to the behavior of MS Outlook and/or Exchange.  As I mentioned earlier, I had to boot to Windows over the last several days.  I did not accept the meetings, as I wanted to perform this in Evolution when I returned to the office and could once again access Exchange without VPN.  But I believe that when I was using Outlook (v2007), that client might actually log a calendar entry when an invite is received, even if you do not accept.  It might be removed later, if you decline, but it appears on your calendar as soon as the invite is received.

So I suspect, that when I returned and started debugging Evolution from my Fedora instance, the meetings that I accepted were found to exist in my calendar and Evolution added the duplicates.  I do not know for sure that this is a bug, or just what one would expect when using both Outlook and Evolution against the same calendar.  If it weren't for VPN (and presuming my past history with Entourage meeting times is resolved) I will not be using Outlook at all.  SO if the latter is the case, I can live with that.

I hope that all of this helps you to clarify the situation, either to help you to a solution, or to provide documentation that with whatever is in the RPM, these such Entourage issues are resolved.

Thanks for the update. From my observation, the server itself can add events into your calendar as soon as it receives the meeting invitation via email. I think it's configurable on the server itself, but I'm not sure.

I think it is just a coincidence that it works currently.

I didn't think of it, but this got fixed upstream recently, in [1], which I failed to recognize as the same issue. evolution-mapi did really set incorrect timezones on events, and meeting invites, which is fixed after [1]. This will be available in 3.4.0 of evoluton-mapi, which is part of Fedora 17.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=669817

Thank you for your help!