A blockchain records when each block was produced despite having no authoritative clock. The stamp comes from the block producer, and the network's job is bounding how wrong it may be.
Clocks are a distributed systems problem
Machines spread across the country and the world disagree about the time by small amounts, and network delay means a message always arrives after it was sent.
There is no way for participants to agree on an exact instant, so a chain cannot simply ask what time it is and record the answer.
What it can do is have each producer assert a time and then reject assertions that other participants find implausible. Agreement becomes a matter of accepted range rather than precision.
The rules that bound a timestamp
Typical rules require a block's stamp to be later than some function of recent blocks and no further ahead than a tolerance measured against each validator's own clock.
A block claiming a time far in the future is simply not accepted yet, and one claiming a time in the distant past fails the backward rule.
The tolerance exists because rejecting blocks over tiny clock differences would fragment the network. Loose bounds keep honest producers from being punished for imprecision.
Why the stamp can still be nudged
Within the permitted window, a producer chooses freely. That freedom is enough to matter when a contract's behavior depends on the recorded time.
Difficulty and reward schedules that key off timestamps can be shifted slightly by producers acting in their own interest, which is why those schedules use long averages.
Contracts that need a deadline are therefore safer measuring in blocks than in seconds, since block counts cannot be manipulated by the same margin.
Proof of stake tightens the schedule
Chains using scheduled slots divide time into fixed intervals with an assigned proposer for each, so the passage of time is structural rather than reported.
This produces regular block intervals and makes the chain's own progress a usable clock, since a missed slot is visible as an empty position rather than as a delay.
The tolerance question does not disappear, because validators still need synchronized clocks to know which slot is current, but the range of disagreement narrows considerably.
What ordering guarantees actually mean
A chain guarantees an order of events, not the true time of events. Two transactions in the same block have no meaningful sequence between them beyond their position in the list.
Applications that treat timestamps as trustworthy inputs are relying on a value that a specific participant supplied under loose constraints.
The dependable property is relative: this happened after that, confirmed by everyone running the rules. Absolute time remains an approximation the network tolerates rather than verifies.