Under some circumstances (not known -- may be to do with updates to existing events but only seems to occur for me with some specific events imported from outside Outlook), Exchange sends a <TimeZone> which is mostly 0.
The TZOFFSETFROM and TZOFFSETTO seem to come out right, but the DTSTART is all zero (invalid). This results in an invalid VTIMEZONE being generated and passed to syncevolution.
Although I don't know what causes Exchange to send this, and it could be argued that the message is invalid because the SYSTEMTIME cannot be all zero, we apparently have to handle this case. It looks like what Exchange is trying to do is to specify a timezone (+0100 in my case) for the event without knowing the real timezone for the event. I suggest that if the starting date-time in the timezone sent from Exchange is zero, that we set it to an arbitrary date in the past. I suggest 1970-01-01, for little good reason.
I plan to investigate this further, and create a fix, but it may not be immediate as my build/test environment is not up to date.
Patches would be welcome. I'm afraid I won't be able (no way to reproduce it, no time) to fix this myself.
Hmm. This may take a little longer. Although I definitely saw this problem, I now can't reproduce it (i.e. persuade Outlook to send me the apparently bad <TimeZone>)!
I will continue to work on it, and see if I can find it. Let's leave this open for now.
Ignore last comment -- I was being stupid. I can reproduce it and now I have added logging it turns out that this is a much more frequent problem than I had realised (at least 10% of my events hit it). The result is that for events which have this problem, the event local time (e.g. 16:00 India time) is re-interpreted as though it were 16:00 UTC (because the VTIMEZONE is invalid and is ignored).
I have a fix and am testing it.
-- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/SyncEvolution/syncevolution/issues/62.