mirror of
https://github.com/aluxnimm/outlookcaldavsynchronizer.git
synced 2026-04-26 11:35:47 +03:00
[GH-ISSUE #148] Trouble synchronizing recurring events created for different timezones - Outlook 2013. #145
Labels
No labels
1.0
1.0
1.0
2.0
Feature
Feature request
Google
Google Calendar
async
attachement
auto-migrated
auto-migrated
auto-migrated
bug
critical
enhancement
help wanted
implemented
pull-request
solved
solved
sourceforge
sourceforge
sourceforge
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/outlookcaldavsynchronizer#145
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @chrishardinge on GitHub (Jul 25, 2016).
Original GitHub issue: https://github.com/aluxnimm/outlookcaldavsynchronizer/issues/148
I'm having an issue with CalDav Synchronizer which prevents it from synchronizing recurring events with timezones that differ from the timezone the calendar currently observes, in Outlook 2013. For example, if my current Outlook calendar is set to Australia/Sydney (AUS Eastern Standard Time) and I create a recurring event for the timezone Australia/Perth (W. Australia Standard Time), the initial sync will succeed, but any sync after modifying the series or occurrence will fail. Synchronization is setup as two-way Outlook<---> Baikal.
Error dump:
iCalendar ICS dump:
@aluxnimm commented on GitHub (Jul 25, 2016):
yes this only works if the event is in the Outlook timezone. some strange bug of the Outlook object model when trying to find the recurrence exceptions. I didn't find a reasonable workaround yet but will investigate further. But sync doesn't fail completely. It is just a warning and it ignores the exceptions cause it can't find them. You can also turn off warnings in general options.
@chrishardinge commented on GitHub (Jul 25, 2016):
Thanks for your prompt reply, aluxnimm. Describing the sync as failing was probably the incorrect terminology - as it does succeed, however it only 'rolls' the SEQUENCE property within the ical and does not actually save the modified occurrence (as a new VEVENT component). Interestingly enough, it does however save any removed occurrences by adding the EXDATE property.
@aluxnimm commented on GitHub (Jul 25, 2016):
What exact version of Outlook, Windows and .net framework are you using? Similar issue is references also in https://social.msdn.microsoft.com/Forums/en-US/13663864-0d35-4eed-8abc-8ade8fce4247/outlook-2013-vsto-error-when-parsing-exceptions-applicationitem-you-changed-one-of-the?forum=outlookdev
Just fixed some related error but couldn't reproduce your error with latest .net and Outlook 2013 anymore.
@chrishardinge commented on GitHub (Jul 25, 2016):
The exact version of Outlook 2013 is 15.0.4833.1000 and is running on Windows 10 Pro build 105836.494 (version 1511). Digging around in the registry, it states .NET 4.6 (version 4.6.01038, Client and Full) and .NET 3.5 (version 3.5.30729.4926) are installed. A .NET detector shows:
Packages Installed:
Have since tried it in Outlook 2016 (version 16.0.6741.2056) on the same OS, which also presents the issue.
@aluxnimm commented on GitHub (Jul 26, 2016):
Can you also provide an example ics file from Outlook export with an recurrence exception that produces this error.
@chrishardinge commented on GitHub (Jul 26, 2016):
My timezone for this test is AUS Eastern Standard Time (Australia/Sydney).
Initial sync of the recurring event (does not produce sync errors):
iCalender after attempting to sync after shifting the 17/08/2016 (New Zealand Standard Time) occurrence forward half an hour:
As you can see above, it fails to add the new VEVENT component for the modified occurrence, but still rolls SEQUENCE. However, if we delete an occurrence on say 23/08/2016 (New Zealand Standard Time) it still displays the error, but rolls the SEQUENCE property and adds the EXDATE property (20160822T200000Z) - shown below:
The SEQUENCE property has jumped from 1 to 3 as Outlook still attempts to sync the occurrence changed prior to the deleted occurrence, hence increments it accordingly. Below is what I'd expect the VEVENT component would look like, if it was added for the 17/08/2016 modification.
@aluxnimm commented on GitHub (Jul 26, 2016):
Your example works in my setup. I have an even older version number of OL2013 and Windows 7.
Do you have Visual Studio 2010 Tools for Office Runtime installed?
https://www.microsoft.com/en-us/download/details.aspx?id=48217
version 10.0.60724
@aluxnimm commented on GitHub (Jul 26, 2016):
And event on server looks like this in my case:
BEGIN:VCALENDAR
PRODID:-//ddaysoftware.com//NONSGML DDay.iCal 1.0//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:New Zealand Standard Time
BEGIN:STANDARD
DTSTART:19700315T030000
RRULE:FREQ=YEARLY;UNTIL=20061231T120000Z;BYMONTH=3;BYDAY=3SU;BYHOUR=3;BYMIN
UTE=0
TZNAME:Neuseeland Normalzeit
TZOFFSETFROM:+1300
TZOFFSETTO:+1200
END:STANDARD
BEGIN:STANDARD
DTSTART:20070318T030000
RRULE:FREQ=YEARLY;UNTIL=20071231T120000Z;BYMONTH=3;BYDAY=3SU;BYHOUR=3;BYMIN
UTE=0
TZNAME:Neuseeland Normalzeit
TZOFFSETFROM:+1300
TZOFFSETTO:+1200
END:STANDARD
BEGIN:STANDARD
DTSTART:20080406T030000
RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU;BYHOUR=3;BYMINUTE=0
TZNAME:Neuseeland Normalzeit
TZOFFSETFROM:+1300
TZOFFSETTO:+1200
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19701004T020000
RRULE:FREQ=YEARLY;UNTIL=20061231T120000Z;BYMONTH=10;BYDAY=1SU;BYHOUR=2;BYMI
NUTE=0
TZNAME:Neuseeland Sommerzeit
TZOFFSETFROM:+1200
TZOFFSETTO:+1300
END:DAYLIGHT
BEGIN:DAYLIGHT
DTSTART:20070930T020000
RRULE:FREQ=YEARLY;UNTIL=20071231T120000Z;BYMONTH=9;BYDAY=-1SU;BYHOUR=2;BYMI
NUTE=0
TZNAME:Neuseeland Sommerzeit
TZOFFSETFROM:+1200
TZOFFSETTO:+1300
END:DAYLIGHT
BEGIN:DAYLIGHT
DTSTART:20080928T020000
RRULE:FREQ=YEARLY;BYMONTH=9;BYDAY=-1SU;BYHOUR=2;BYMINUTE=0
TZNAME:Neuseeland Sommerzeit
TZOFFSETFROM:+1200
TZOFFSETTO:+1300
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
CLASS:PRIVATE
DTEND;TZID=New Zealand Standard Time:20160803T090000
DTSTAMP:20160726T193446Z
DTSTART;TZID=New Zealand Standard Time:20160803T080000
PRIORITY:5
RRULE:FREQ=WEEKLY;COUNT=14;BYDAY=TU,WE
SEQUENCE:3
SUMMARY:Test Timezone
TRANSP:OPAQUE
UID:4fcfcd50-e229-498d-8c76-c43afef1cd73
X-MICROSOFT-CDO-BUSYSTATUS:BUSY
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:This is an event reminder
TRIGGER:-PT15M
END:VALARM
END:VEVENT
BEGIN:VEVENT
CLASS:PRIVATE
DTEND;TZID=New Zealand Standard Time:20160817T093000
DTSTAMP:20160726T193454Z
DTSTART;TZID=New Zealand Standard Time:20160817T083000
PRIORITY:5
RECURRENCE-ID:20160816T200000Z
SEQUENCE:4
SUMMARY:Test Timezone
TRANSP:OPAQUE
UID:4fcfcd50-e229-498d-8c76-c43afef1cd73
X-MICROSOFT-CDO-BUSYSTATUS:BUSY
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:This is an event reminder
TRIGGER:-PT15M
END:VALARM
END:VEVENT
END:VCALENDAR
@chrishardinge commented on GitHub (Jul 26, 2016):
I'm going to assume the tool had previously been installed as the CalDav Synchronizer installer never prompted for it, as per the instructions. Nevertheless, installing/reinstalling Visual Studio 2010 Tools for Office Runtime from the link you provided, restarting the PC and clearing CalDav Synchronizer's cache for good measure, seems to have done the trick. Modified occurrences are having their VEVENT components synchronized as expected now.
Thanks for your help, aluxnimm - it is greatly appreciated. Cheers.
@aluxnimm commented on GitHub (Jul 27, 2016):
that are great news! thx for confirmation because others have similar issues and now we know how to fix them. The installer doesn't always detect the vsto runtime missing and needs to be improved if we have some time btw.