On Mon, 2014-10-27 at 23:25 +0000, Graham Cobb wrote:
On 20/10/14 13:02, Patrick Ohly wrote:
> On Mon, 2014-10-20 at 10:17 +0100, Graham Cobb wrote:
>> I have just noticed, in my testing of 18.104.22.168, 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 haven't yet changed any code but I have looked at the code and the
logs. The situation is complicated slightly by the fact that we (in the
UK) are now back on winter time, which is GMT (=UTC). However, I can
reproduce the problem by looking at all day events set up for next summer.
In the activesyncd log I can see the event coming in from EAS with:
The start time is midnight local time (on the day of the event,
20150729, which is BST -- summer time).
I also see, in the log...
(process:16804:0xcb3c50): libeas-DEBUG:process timezone
AFAAEAAAAAAAAAxP///w== => bias 0, standard bias 0, daylight bias -60,
standard '(UTC) Dublin, Edinburgh, Lisbon,', daylight '(UTC) Du
blin, Edinburgh, Lisbon,'
I have not yet added debug logging to
_eas2ical_convert_datetime_property but I assume this is not being
correctly converted to midnight local time and hence is failing the
"sanity check" in that function. Of course, if that is the case, the
sanity check is not the problem -- the "local time" is wrong and will
still be 23:00 on the day before (but a log message to warn about the
sanity check failure would be useful).
Any idea why icaltime_convert_to_zone would not be converting the time
to 00:00 BST?
No, not without actually stepping through the code.
Is the timezone info Exchange is providing wrong? I am not certain
exactly what the log "process timezone" message is showing, but it
doesn't look right that daylight claims to be UTC. But I am not sure
whether that text is actually important.
I think it's no used.
One thing to check is what time zone is used internally. Is it the one
sent by Exchange converted to VTIMEZONE or some system timezone
corresponding to it? I don't remember whether we got around to
implementing such a matching, or how complete it is.
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.