Bug 91318 - Exchange can send TimeZone with zero StandardDate
Summary: Exchange can send TimeZone with zero StandardDate
Status: RESOLVED MOVED
Alias: None
Product: SyncEvolution
Classification: Unclassified
Component: ActiveSync (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: SyncEvolution Community
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-12 16:05 UTC by Graham Cobb
Modified: 2018-10-13 12:41 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Graham Cobb 2015-07-12 16:05:42 UTC
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.
Comment 1 Patrick Ohly 2015-07-13 10:42:55 UTC
Patches would be welcome. I'm afraid I won't be able (no way to reproduce it, no time) to fix this myself.
Comment 2 Graham Cobb 2015-07-19 11:46:19 UTC
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.
Comment 3 Graham Cobb 2015-07-19 15:23:06 UTC
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.
Comment 4 GitLab Migration User 2018-10-13 12:41:20 UTC
-- 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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.