Why daily agent spend totals disagree: time zones and day boundaries
GetAgentCap team · published 10/10/2026
Two systems can read the same on-chain payments and still report different totals for "yesterday". The usual cause is not a missing transfer. It is that they disagree about when a day starts and which timestamp counts.
Three clocks, not one
A payment has at least three moments attached to it: when the agent made the request, when the transaction was submitted, and when the block containing it was produced. These can differ by seconds or, during congestion or retries, by much more.
A report that buckets by request time and a report that buckets by block time will put a payment near midnight in different days.
UTC versus local time
Block timestamps are absolute instants. Turning them into calendar days requires choosing a time zone, and a dashboard in one zone will not match a spreadsheet in another for any payment close to the boundary.
Daylight saving changes make this worse in local time, because some days have 23 hours and some have 25. UTC has no such days, which is why it is the safer default for anything you intend to reconcile.
Block time is not wall-clock time
A block's timestamp is set by the chain's producer and is approximate. Treat it as accurate to a few seconds, not to the millisecond, and don't build logic that depends on exact ordering between transactions from different sources.
For a payment that is close to a day boundary, the right behavior is to pick one rule, apply it everywhere, and write it down.
A practical rule
Bucket by block timestamp in UTC, and state that in every report. When someone compares your total to another tool's, the first question to ask is which timestamp and which zone it used.
If the totals still differ after aligning both, the cause is real, such as a missed transfer, a duplicate, or a reorg, and that is the discrepancy worth investigating.