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
been in my OpenSync days (or even my own OWASync!).
I have just noticed, in my testing of 188.8.131.52, 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
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.
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.