I have submitted three patches to bug 85239. One of them fixes the actual problem I was seeing, the other two are related but separate (see the comments in the bug report).
However, as I was testing these, the improved logging found many cases where Exchange was providing the wrong timezone information. Most events had the correct timezone but some did not (some of those were invitations received from other people, others were events I created on another device using EAS, others I don't know). In all those cases, the event was actually timed to start/finish at midnight UK time, but some other timezone (normally CET) was being provided. So, when the events were converted to (apparent) local time, their times were not midnight. I don't see any good workround for this: as Exchange is lying about the timezone it is hard to fix. We could use the system timezone instead of the timezone Exchange reports, but that is likely to be wrong in many cases. At the moment, when the time check fails, the code just gives up and uses the time sent by Exchange (which is in UTC). When this gets turned into just a date, it is likely to be the wrong day (depending on whether the event is really ahead or behind UTC). My thought is to force the event to not be treated as an "all day" event if the time fails the midnight check. Not perfect, of course (it loses the information that it is an all day event), but it allows the user to get a better idea of what has gone wrong and gives them a better chance of recognising the correct day. Of course, it is likely to really mess up round-trip processing of the events -- they may get marked by Exchange as no longer all-day when they get synced back. Thoughts? Graham _______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
