You are right on this. Unfortunately it is not easy to fix because we do not keep track of delays while processing an item.
hmm, this seems to be the biggest problem when using proxies. in that case we do know when item value was collected, so we should compare against that (and assume that proxy has synchronised clock, of course).
with active items that would be useless, as then we would compare value to time, taken on the same host 
A somewhat related issue: ZBXNEXT-2045.
Note we've found this also breaks even without proxies when the DB is slow - if the DB sync processes get behind due to backups or housekeepers, etc. then the times mismatch, too (since the trigger is evaluated when written to the DB). I'd think Active Checks that were delayed at all due to network, etc. would also be affected.
In practice this makes time checks for hosts nearly useless in lots of environments, even though this is critically important for many people (especially those on Kerberos).
How do other systems deal with this ? No proxies I guess, and no active checks. It's a hard problem with Proxies & Actives & Delayed Evaluation - all help Zabbix scale, but leave us no way to check time. We'll do a separate SQL process for this, I think with sender to check last 24 hours time drift so smooth out these effects (average diff between clock and value over 24 hours).