Description of problem: Recently, when I receive *some* calendar invites, the timezone in the ICS file is ignored, and the entry is listed in my EWS Calendar as timezone: Etc/GMT My EWS account is now on Office 365. I'm not certain if ALL of my colleagues are on Office 365 yet, as I suspect some may still be on the on-premise server. My normal time zone is Africa/Johannesburg or GMT+2. Version-Release number of selected component (if applicable): evolution-3.28.5-1.fc28.x86_64 evolution-data-server-3.28.5-1.fc28.x86_64 evolution-data-server-debuginfo-3.28.5-1.fc28.x86_64 evolution-data-server-debugsource-3.28.5-1.fc28.x86_64 evolution-data-server-langpacks-3.28.5-1.fc28.noarch evolution-debuginfo-3.28.5-1.fc28.x86_64 evolution-debugsource-3.28.5-1.fc28.x86_64 evolution-ews-3.28.5-1.fc28.x86_64 evolution-ews-langpacks-3.28.5-1.fc28.noarch evolution-help-3.28.5-1.fc28.noarch evolution-langpacks-3.28.5-1.fc28.noarch How reproducible: Today I received an ICS file with the below detail and imported this into my EWS calendar. The time zone shows as Etc/GMT and consquently the entry is displayed in the wrong local time (2 hours ahead). My timezone is Africa/Johannesburg or GMT+2 (South Africa). BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 16.0 MIMEDIR//EN VERSION:2.0 METHOD:PUBLISH X-MS-OLK-FORCEINSPECTOROPEN:TRUE BEGIN:VTIMEZONE TZID:South Africa Standard Time BEGIN:STANDARD DTSTART:16010101T000000 TZOFFSETFROM:+0200 TZOFFSETTO:+0200 END:STANDARD END:VTIMEZONE BEGIN:VEVENT CLASS:PUBLIC CREATED:20180823T131805Z DESCRIPTION: \n DTEND;TZID=South Africa Standard Time:20180831T140000 DTSTAMP:20180823T131805Z DTSTART;TZID=South Africa Standard Time:20180831T130000 LAST-MODIFIED:20180823T131805Z LOCATION:BCX Centurion\, Multifunction rooms / VC rooms in regions PRIORITY:5 SEQUENCE:0 SUMMARY;LANGUAGE=en-za:Connect with KC TRANSP:OPAQUE UID:040000008200E00074C5B7101A82E00800000000E0545458F43AD401000000000000000 0100000000F99579308EA184F89B12720EBEFAB52 X-ALT-DESC <--snip -- too long --> X-MICROSOFT-CDO-BUSYSTATUS:BUSY X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-DISALLOW-COUNTER:FALSE X-MS-OLK-AUTOFILLLOCATION:FALSE X-MS-OLK-CONFTYPE:0 BEGIN:VALARM TRIGGER:-PT15M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR Steps to Reproduce: 1. Receive a calendar invite from a colleague. 2. Event is filed 2 hours ahead in the calendar. 3. Incorrect entry shows the time zone of Etc/GMT. Actual results: When I send an invite from GMAIL, it appears in the correct time slot. When I receive an invite from a colleague as shown above it appears in the wrong time slot. Expected results: Additional info:
Thanks for a bug report. This sounds like [1], but it is included in evolution-ews 3.28.5. I tested with the current development version (just after 3.30.0 release) and I can reproduce it simply by importing your event into an EWS calendar, the timezone is reset to UTC. It seems that evolution-ews failed to find corresponding timezone for the one stored in the iCalendar object. [1] https://gitlab.gnome.org/GNOME/evolution-ews/issues/7
When a non-libical timezone had been used in a meeting invitation component or in an iCalendar object being imported, it were not found in the local timezone cache, which caused reset of the timezone to UTC. Created commit [1] in ews master (3.31.1+) Created commit [2] in ews gnome-3-30 (3.30.1+) [1] https://gitlab.gnome.org/GNOME/evolution-ews/commit/06b9eff5 [2] https://gitlab.gnome.org/GNOME/evolution-ews/commit/c124fae3
evolution-ews-3.28.5-2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-6f26f06eea
evolution-ews-3.28.5-2.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-6f26f06eea
evolution-ews-3.28.5-2.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.