The two clocks every search result should carry

Ask an award tool when its result is from, and most will show you one timestamp. That single number quietly merges two different clocks, and the gap between them is precisely where stale data hides.

Clock one: when we fetched

The first clock is the tool’s own: the moment it acquired the bytes it is showing you. This clock is always available and always honest about one thing only — how old the tool’s copy is.

Clock two: when the source last checked

The second clock belongs to the source. Some programs publish, inside their own responses, when their availability engine last refreshed the answer. A tool can fetch a response one minute ago that the source itself computed twenty hours earlier — a perfectly fresh copy of a stale fact.

A fresh copy of a stale fact is still a stale fact.

The failure mode compounds when tools cache each other. An aggregator fetches from a source that cached an airline’s answer; a browser extension screenshots the aggregator; a forum post quotes the screenshot. Each hop restamps the data with a newer time, and by the fourth hop a two-day-old availability snapshot is presented as live. Nobody lied at any single step. The lie is emergent.

What to demand from a tool

• Both clocks, shown separately, never averaged into a vague “updated recently”.
• An honest “we do not know” where the source publishes no clock of its own — a tool that always has a source timestamp is manufacturing some of them.
• Stale results that say so, rather than quietly looking identical to fresh ones.

Every result in this product shows when we fetched and, where the program publishes one, when the program itself last checked. Where it does not, the second clock reads as unavailable — because for that program, it is. That is the whole design: two clocks, no averaging, and the age of every answer on its face.