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.