Home → Help
Usage log timestamps do not match when you made the call
Most platforms store timestamps in UTC and display them either in UTC or in a timezone you set once and forgot. Comparing a local clock against a UTC log shifts every boundary, which is why totals disagree at the edges of a day.
What you are seeing
A request you just made appears with yesterday's dateDaily totals do not match what you countedNothing in the log for the hour you were testingTwo tools report different totals for the same day
Why it happens
Daily aggregates are computed on a day boundary. If yours is UTC and you think in UTC+8, eight hours of calls land in what you consider the previous day — the data is all there, grouped differently.
Client-side timestamps come from the machine that made the call. A server with a wrong clock or a different timezone produces a log that looks inconsistent with itself.
Filters commonly default to the last 24 hours rather than today. That window moves as you look at it, which makes a total appear to change on its own.
How to fix it
- Compare in UTC on both sidesConvert your own records to UTC before reconciling. Doing it the other way needs the platform's display timezone, which is easy to get wrong.
- Look up the specific request rather than the daySearch by request id or by model and approximate time. A single record either exists or does not, with no boundary to argue about.
- Check the caller's clockIf your own logs disagree with the platform by a consistent offset that is not a whole number of hours, suspect clock drift on the calling machine.
APICLAN stores every call in UTC with its exact charge. If a request is genuinely absent rather than shifted, that usually means it never reached the gateway — a path or base URL mistake, which leaves no record at all.
Related
Last checked 2026-10-01. Written from problems diagnosed on a live
OpenAI-compatible gateway, not collected from other sites.