Bug ID 85239
Summary ActiveSync does not handle Outlook all day events correctly
Product SyncEvolution
Version 1.4
Hardware Other
OS Linux (All)
Status NEW
Severity normal
Priority medium
Component ActiveSync
Assignee syncevolution-issues@syncevolution.org
Reporter g+syncevolution@cobb.uk.net
CC syncevolution-issues@syncevolution.org

Discussion from mailing list...

On Mon, 2014-10-20 at 10:17 +0100, Graham Cobb wrote:
> I know I have had trouble with all day events before, but it might have
> been in my OpenSync days (or even my own OWASync!).
> I have just noticed, in my testing of, that all day events are
> not working properly.  I don't suppose this is new in this version -- I
> probably didn't notice it before.

Right. That code hasn't changed in quite a while. The relevant code to
look at are the _eas2ical_convert_datetime_property() and
_eas2ical_convert_component() methods

> I have an all day event in Outlook, scheduled for this Thursday
> (20141023). I did a one-way sync from Exchange (activesync) to files,
> and the file ended up with the following:
> To make matters worse, I then synced those files with Owncloud and
> Owncloud now believes this is an all day event on the 22nd! (And so does
> Thunderbird when I synced that against Owncloud).
> I have not yet attempted to debug this (looking at what activesync
> sends, etc) but wondered if anyone either has seen this before, or has a
> view on what the correct VCALENDAR file should look like for this event.

Correct for an all-day event on (and just on) the 23rd would be:


The end date(-time) is exclusive.

The key problem with the conversion is that Microsoft requires putting a
time into the start and end fields. But which time does an all-day event
start and end at? Local time? UTC? Does it depend on where someone is?

This is all not defined in the Microsoft documentation. It only
documents a flag that marks an event as all-day.

If I remember correctly, in practice it had to be the local time of the
user. So if I am in GMT+2, the 00:00 time as to be shifted by two hours,
thus causing the date to also change. Obviously this shift goes wrong
when the time zones are not set correctly (or at least consistently). I
have no idea how that is supposed to be handled correctly in all cases.

You are receiving this mail because: