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 1.4.99.4, 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 > > activesyncd/eas-daemon/libeas/eas-cal-info-translator.c. > > 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: > > <TimeZone > xmlns="Calendar:">AAAAACgAVQBUAEMAKQAgAEQAdQBiAGwAaQBuACwAIABFAGQAaQBuAGIAdQByAGcAaAAsACAATABpAHMAYgBvAG4ALAAAA > AoAAAAFAAIAAAAAAAAAAAAAACgAVQBUAEMAKQAgAEQAdQBiAGwAaQBuACwAIABFAGQAaQBuAGIAdQByAGcAaAAsACAATABpAHMAYgBvAG4ALAAAAAMAAAAFAAEAAAAAAAAAxP > ///w==</TimeZone> > <StartTime xmlns="Calendar:">20150728T230000Z</StartTime> > <AllDayEvent xmlns="Calendar:">1</AllDayEvent> > > 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 > AAAAACgAVQBUAEMAKQAgAEQAdQBiAGwAaQBuACwAIABFAGQAaQBuAGIAdQByAGcAaAAsACAATABpA > HMAYgBvAG4ALAAAAAoAAAAFAAIAAAAAAAAAAAAAACgAVQBUAEMAKQAgAEQAdQBiAGwAaQBuACwAIABFAGQAaQBuAGIAdQByAGcAaAAsACAATABpAHMAYgBvAG4ALAAAAAMAAA > 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. _______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
