On 28/10/14 08:59, Patrick Ohly wrote: > 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. >
Found it. The bug is in _eas2ical_process_timezone. This comment: // if timezone id contains character UTC and Bias is 0, then don't add it to the ICAL This attempted optimisation is not safe, of course, if the daylight time is not UTC. In fact, the code already does the correct optimisation higher up -- if **both** standard and daylight are UTC don't bother with the timezone. This only affects us in the UK (and Ireland and Portugal)! I will generate a patch shortly and add it to the bug report. Graham _______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
