Thanks for a bug report. Would it be possible to attach here one such event saved from the evolution as an iCalendar file (context menu of the event), please?

(In reply to Milan Crha from comment #1)
> Thanks for a bug report. Would it be possible to attach here one such event
> saved from the evolution as an iCalendar file (context menu of the event),
> please?

Did you receive the ICS file I sent privately? The data in it cannot be shared, so I cannot attach it here.

(In reply to Bojan Smojver from comment #2)
> Did you receive the ICS file I sent privately? The data in it cannot be
> shared, so I cannot attach it here.

Sure, I did. It exhibited the issue in 3.20.5, I only didn't let you know. I'm sorry. I was about to test it further, but then other things got before it in the priority queue, afterwards I forgot of it a bit.

Thanks. Was just making sure that it didn't land in junk folder. :-)

No rush at all.

The current development version doesn't show event details in your message at all, for some reason. That will be fixed first. Then I'll check the timezone thing, I hope I wasn't wrong with my previous findings.

Hmm, I re-tried and it seems I'm not able to reproduce this in 3.20.5. What I did:
a) I explicitly set my timezone to America/Sydney, not using "Use system timezone"
   checkbox in the Calendar and Tasks Preferences.
b) I opened your mail and it showed the event from 4:30 to 5:00 AM
c) when I saved the event and imported it into a local calendar it also showed
   it from 4:30 to 5:00 AM and the tooltip said "14:30 America/New_York,
   for 30 minutes"

From that I'd say the the evolution failed to recognize your timezone in the settings for some reason. Can you see the meeting time difference in your Sent folder too, on the message you sent me? I can generate a similar message with an invitation which is not private, for easier testing.

For some reason only happens with inbox. Messages in sent folder show correct time.

Maybe I should force time zone settings in Evo and try again.

View the message source of one of the affected invitations and check what DTSTART/DTEND is shown there. In case the vent being base64 encoded, use
   $ base64 -d
to decode it and see the DTSTART/DTEND values. The event you sent me privately is base64 encoded and shows after the decode:

   DTSTART;TZID=/freeassociation.sourceforge.net/America/New_York:
    20160823T143000
   DTEND;TZID=/freeassociation.sourceforge.net/America/New_York:
    20160823T150000

The timezone is also included in the VCALENDAR part, at the top of the file:

   BEGIN:VTIMEZONE
   TZID:/freeassociation.sourceforge.net/America/New_York
   X-LIC-LOCATION:America/New_York
   ...

Yeah, I did view the source one of them. Everything looked in order, just like in your analysis. Additionally, Good mail client correctly converts US time zones to mine with every invite, so I know source is not the problem.

If the Inbox messages show times wrong, but the message source shows correct data, then I cannot think of anythign else but that the timezone preference read failed in some way for some reason. Is it reliable reproducible with the messages in the MAPI Inbox? What if you copy the message to an On This Computer folder (drag&drop, or right-click and "Copy Messages to..."), will the message still show a wrong time?

(In reply to Milan Crha from comment #10)
> If the Inbox messages show times wrong, but the message source shows correct
> data, then I cannot think of anythign else but that the timezone preference
> read failed in some way for some reason. Is it reliable reproducible with
> the messages in the MAPI Inbox?

Yes. Any invite emails that I receive (into any folder, not just inbox) show with the original timezone. Responses I send show with the correct (my own) time zone. Accepted events in the calendar view show correctly as well.

I tried forcing the time zone to Australia/Perth, for instance, in calendar preferences, but that made no difference at all.

> What if you copy the message to an On This
> Computer folder (drag&drop, or right-click and "Copy Messages to..."), will
> the message still show a wrong time?

Tried that. Still shows the same thing - invite is in the original time zone.

Side note, I'm pretty sure access to anything at sourceforge.net is forbidden on the network where this problem occurs. Given that the timezone is encoded as /freeassociation.sourceforge.net/America/New_York, could that be related?

(In reply to Bojan Smojver from comment #11)
> > What if you copy the message to an On This
> > Computer folder (drag&drop, or right-click and "Copy Messages to..."), will
> > the message still show a wrong time?
> 
> Tried that. Still shows the same thing - invite is in the original time zone.

Weird. I'll create for a you a test build, which will print some valuable information on the console. I hope it'll help to figure out what's going wrong here.

(In reply to Bojan Smojver from comment #12)
> Side note, I'm pretty sure access to anything at sourceforge.net is
> forbidden on the network where this problem occurs. Given that the timezone
> is encoded as /freeassociation.sourceforge.net/America/New_York, could that
> be related?

No no, that's okay, it's only a time zone ID, which happens to be prefixed with the URL-like text. It doesn't download anything from that site.

You can find the test build here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=15436257

Click one of the builds (i686 for you), which will offer you respective packages. Download those you've installed for the evolution and update them using:

   # dnf update ./evolution*.rpm

Then run the evolution from a console and select one of the messages with meeting invitation which shows incorrect start time. The console will contain some debugging information, which I'd like to see. It also prints the raw component it uses for the view, which contains private information. I'd like to see the DTSTART line and couple surrounding to it, not a whole component right now. It will be also interesting whether it contains any VTIMEZONE-s. it prints for the invite you sent me privately:

> extract_itip_data: parsing ---BEGIN:VCALENDAR
> PRODID:-//Ximian//NONSGML Evolution Calendar//EN
> VERSION:2.0
> METHOD:PUBLISH
> BEGIN:VTIMEZONE
> TZID:/freeassociation.sourceforge.net/America/New_York
> X-LIC-LOCATION:America/New_York
> BEGIN:STANDARD
> ....
> END:VTIMEZONE
> BEGIN:VEVENT
> ....
> DTSTART;TZID=/freeassociation.sourceforge.net/America/New_York:
>  20160823T143000
> DTEND;TZID=/freeassociation.sourceforge.net/America/New_York:
>  20160823T150000
> ...
> END:VEVENT
> END:VCALENDAR
> ---
>    itip_view_init_view: location in settings: 'Australia/Sydney' found:0x19d5a78 (id:/freeassociation.sourceforge.net/Australia/Sydney loc:Australia/Sydney)
>    itip_view_init_view: dtstart has tzid:'/freeassociation.sourceforge.net/America/New_York'
> itip_view_init_view: from:0x50d6360 (America/New_York|/freeassociation.sourceforge.net/America/New_York) to:0x19d5a78 (Australia/Sydney|/freeassociation.sourceforge.net/Australia/Sydney)
>    itip_view_init_view: DTSTART is_date:0 time: 2016-08-24 4:30:00

Which looks correct.

Just sent the output that was generated by clicking on one such event privately. Hope it helps.

And looking at the output of what I got, the (nil) there seems to be what's happening:
---------------------
   itip_view_init_view: using system timezone as the target zone (0x822fee24 (id:/freeassociation.sourceforge.net/Australia/Sydney loc:Australia/Sydney))
   itip_view_init_view: dtstart has tzid:'/freeassociation.sourceforge.net/America/New_York'
itip_view_init_view: from:(nil) (|) to:0x822fee24 (Australia/Sydney|/freeassociation.sourceforge.net/Australia/Sydney)
   itip_view_init_view: DTSTART is_date:0 time: 2016-08-16 12:30:00
---------------------

Yes, that's it. While the component snippet in comment #14 contains also VTIMEZONE sub-component, the one printed in your debug output doesn't have it, it has only the VEVENT subcomponent. That's the cause why the search for the 'from' timezone failed. I think of two places to fix, one on the itip view side, to try harder to catch the 'from' timezone and on the evolution-mapi side (maybe also on the evolution-ews side), to include also timezones in the generated components in the invitations.

Fix for the evolution [1] and for the evolution-mapi [2], both will be released in 3.21.92+ version of respective component. The chang eon the evolution side makes sure also the old meeting invitations are shown properly, otherwise the old mails should be re-downloaded to take the change into the effect.

[1] https://git.gnome.org/browse/evolution/commit/?id=761ac9f
[2] https://git.gnome.org/browse/evolution-mapi/commit/?id=96fd087

I think this may have introduced something into the code that makes accepting meeting requests to be saved with the wrong time.

Example:

I'm in AEDT time zone (Sydney) and I get meeting requests with EST (Boston) time zone. When I accept them in Good for Enterprise, they are correctly translated into AEDT time. If I do the same in Evolution, the meeting gets pushed 15 hours back, which happens to be the current time difference between AEDT and EST.

So, something is still not quite right here.

Weird, I do not seem to be able to reproduce it. I made a meeting in a different timezone than I use in the evolution and sent it myself. Before it had been sent from an Outbox folder I moved it elsewhere, then I opened it from there and it showed me that the meeting could not be found and asked me what to do. I told it to add to a MAPI calendar, which it did. The meeting shows with the correct timezone for me. This is with an Exchange 2007 server.

(In reply to Milan Crha from comment #20)
> This is with an Exchange 2007 server.

I think my guys are probably using 2010. Anyhow, the meetings I'm receiving are created by other folks with Outlook (or maybe Good for Enterprise).

When I get another one, I'll try to figure out a bit more what's going on.

Here is what I did. I sent myself a meeting request form Outlook 2010, set for 13 Dec 2016 at 6 pm CST. I accepted this in Evo. Evo calendar shows the appointment at 14 Dec 2016 at 11 am AEDT, which is correct. Outlook shows the appointment at the correct time as well.

However, Good for Enterprise show this appointment at 15 Dec 2016 AEDT at 5 am. So, this may be a Good for Enterprise bug after all.

Could you verify what timezone is set on the event, please? Both the one you received by email (in the Message source [Ctrl+U]) and then when you right-click it in the Calendar view and will pick 'Save as iCalendar'. The lines wit DTSTART and DTEND define the event time, possibly with TZID as the timezone ID.

If it'll show sane values, then I tend to agree with the bug being elsewhere.

Thanks for the files (sent to me privately). All of them show America/Chicago timezone being used for the event, which seems correct, from my point of view (and is considered a "sane value" from my point of view).

The two events you see in the UI have different unique identifier, even they both reference the same MAPI's GlobalID. I guess it's due to one event being added to the calendar by the evolution, the other being updated by the server, even it's only a guess. Issuing a Refresh on the calendar should remove one of them.

(In reply to Milan Crha from comment #24)
> Issuing a Refresh on the calendar should remove one of them.

Tried that, but it didn't work. If I do evolution --force-shutdown, the second event indeed disappears on restart.

That's because the evolution-calendar-factory process got restarted and the local in-memory-cache updated. It can be that the MAPI failed to pair the events, but as I said, they have a different UID, which is a unique identifier of the component. I know this is unrelated for the initial issue in this bug report, I'm only mentioning it.