Foundations: monotonic clocks and deadlines

Date.now() - startedAt looks like elapsed time, but the wall clock is allowed to move.

A laptop can synchronize backward. A virtual machine can resume. A phone can sleep through a timer. A browser can throttle a background tab. A process can restart and lose its monotonic origin. Two servers can disagree about the current instant while each measures local duration correctly.

The current W3C High Resolution Time draft distinguishes a wall clock that follows the user's notion of time from a monotonic clock that never decreases within its scope. It recommends monotonic time for measurement and wall time for communication, while warning that monotonic properties do not survive every browser execution boundary.

That distinction changes API design. Durations should come from a monotonic source. User-visible dates and durable cross-process instants need wall time plus timezone context. Multi-hop work should carry an absolute deadline or remaining budget with explicit clock assumptions instead of giving every layer a fresh timeout.

Time bugs become tractable when the question comes before the clock call.

Name the time question

Ask whether the system needs a civil timestamp, ordering, elapsed duration, cadence, timeout, deadline, freshness, or schedule before choosing an API.

I would pressure-test that decision with four questions:

• What question is answered?
• Who compares the value?
• Across which boundary?
• Can the clock adjust?

The failure mode here is using one timestamp type for every temporal concern. In browser, mobile, backend, distributed, and real-time systems where wall-clock adjustments, suspend and resume, process restarts, network delay, timer throttling, leap behavior, clock skew, and persistence can invalidate elapsed-time assumptions, that can hide the exact boundary a reviewer or teammate needs to understand. My working artifact would be a time-question classification. I want it close enough to the implementation that it can change the work, not created afterward to decorate the story.

The result I would look for is clock semantics matched to the product decision. That is a narrower claim than saying the whole system improved, but it is also one I can verify and defend.

In practice, I would put a time-question classification beside the question “What question is answered?” before the first implementation review. The next pass would use “Who compares the value?” to test the boundary, then “Across which boundary?” to expose the state most likely to be missed. I would keep “Can the clock adjust?” for the release check because it asks whether the decision still holds outside the ideal path. The work is ready to move when the artifact can explain the choice and the observed result supports clock semantics matched to the product decision.

Separate wall and monotonic clocks

Wall time approximates shared civil time and may adjust; monotonic time advances within a defined scope and is appropriate for measuring local intervals.

The practical review starts here:

• Can time move backward?
• Does the origin matter?
• Must values cross processes?
• Will a person read it?

Those questions keep measuring latency by subtracting adjustable civil timestamps from becoming the default. I would capture the decision in a clock-choice table, then use it while the work is still cheap to change. For time-dependent behavior that remains correct when clocks and execution contexts change, the artifact should make ownership, constraint, and next action visible without requiring a private explanation.

Success would look like non-negative trustworthy local durations and honest shared timestamps. If I cannot point to that evidence, I have a direction, not a finished decision.

The implementation move is to make a clock-choice table part of the working surface. I would use it to answer “Can time move backward?” while scope is still flexible, and “Does the origin matter?” before code or content becomes expensive to unwind. During QA, “Must values cross processes?” and “Will a person read it?” become concrete checks rather than discussion prompts. That sequence turns time-dependent behavior that remains correct when clocks and execution contexts change into something the team can operate and gives me a specific outcome to report: non-negative trustworthy local durations and honest shared timestamps.

Measure differences, not origins

A monotonic value is useful through subtraction within compatible origins; serializing it as an absolute instant invents meaning it does not have.

Before implementation, I would answer:

• Which origin produced it?
• Can contexts exchange values?
• Will restart reset it?
• Is only the duration needed?

The artifact is a monotonic-origin boundary note. Its job is to expose the tradeoff early enough that design, engineering, support, or product can disagree with something concrete. The common trap is storing performance.now as if it were epoch milliseconds; it moves uncertainty downstream and makes the final interface carry a problem the system never resolved.

For me, the useful receipt is duration measurements that stay inside their valid scope. That connects a clock-selection discipline that separates user-visible wall time from monotonic duration measurement, converts timeout chains into budgets and deadlines, scopes monotonic values to one execution, and records both intent and observed timing to an observable result instead of a process claim.

I would test this with one typical case and one boundary case. The typical case should make “Which origin produced it?” easy to answer. The boundary should force a decision about “Can contexts exchange values?” and “Will restart reset it?.” I would record both in a monotonic-origin boundary note, including the part that stayed unresolved after the first pass. The final check, “Is only the duration needed?,” is where the artifact earns its place: it either supports duration measurements that stay inside their valid scope, or it shows exactly why another iteration is needed.

Propagate one deadline

A request chain should share a total budget so queueing and downstream work consume the same promise rather than resetting timeout at every hop.

I would use these prompts during the working review:

• When did the budget begin?
• How much remains?
• Which margin is reserved?
• Does cancellation propagate?

If the team slips into giving each of five services a fresh three-second timeout, the product can still look complete while its operating rule stays ambiguous. I would make an end-to-end deadline budget the shared reference and keep it small enough to update as evidence changes.

The standard is bounded user latency across the complete operation. That tells me whether the decision helped the product, not merely whether the document was completed.

The working sequence is small: draft an end-to-end deadline budget, review it against “When did the budget begin?,” implement the narrowest useful path, and then return with evidence for “How much remains?.” I would use “Which margin is reserved?” to inspect product consequence and “Does cancellation propagate?” to decide whether the result is stable enough to ship. This keeps giving each of five services a fresh three-second timeout visible as a known risk and makes bounded user latency across the complete operation the release receipt rather than a hopeful conclusion.

Account for suspend and throttling

Monotonic clocks may continue while callbacks do not run, so elapsed time and executed work can diverge after sleep, background throttling, or process pause.

I would pressure-test that decision with four questions:

• Does the clock include suspend?
• Can the callback be delayed?
• What happens on resume?
• Should stale work continue?

The failure mode here is assuming setTimeout fires at its requested instant. In browser, mobile, backend, distributed, and real-time systems where wall-clock adjustments, suspend and resume, process restarts, network delay, timer throttling, leap behavior, clock skew, and persistence can invalidate elapsed-time assumptions, that can hide the exact boundary a reviewer or teammate needs to understand. My working artifact would be a suspend-and-resume behavior table. I want it close enough to the implementation that it can change the work, not created afterward to decorate the story.

The result I would look for is safe resume behavior based on current deadline and product value. That is a narrower claim than saying the whole system improved, but it is also one I can verify and defend.

In practice, I would put a suspend-and-resume behavior table beside the question “Does the clock include suspend?” before the first implementation review. The next pass would use “Can the callback be delayed?” to test the boundary, then “What happens on resume?” to expose the state most likely to be missed. I would keep “Should stale work continue?” for the release check because it asks whether the decision still holds outside the ideal path. The work is ready to move when the artifact can explain the choice and the observed result supports safe resume behavior based on current deadline and product value.

Bound restart semantics

Process and browser restarts can reset monotonic origins and erase timers; durable operations need wall-clock intent, persisted state, and reconciliation on startup.

The practical review starts here:

• What survives restart?
• Is the deadline persisted?
• Can intent be replayed?
• How is overdue work classified?

Those questions keep persisting only an in-memory remaining-duration counter from becoming the default. I would capture the decision in a restart recovery contract, then use it while the work is still cheap to change. For time-dependent behavior that remains correct when clocks and execution contexts change, the artifact should make ownership, constraint, and next action visible without requiring a private explanation.

Success would look like reconstructed deadlines without treating old monotonic values as current. If I cannot point to that evidence, I have a direction, not a finished decision.

The implementation move is to make a restart recovery contract part of the working surface. I would use it to answer “What survives restart?” while scope is still flexible, and “Is the deadline persisted?” before code or content becomes expensive to unwind. During QA, “Can intent be replayed?” and “How is overdue work classified?” become concrete checks rather than discussion prompts. That sequence turns time-dependent behavior that remains correct when clocks and execution contexts change into something the team can operate and gives me a specific outcome to report: reconstructed deadlines without treating old monotonic values as current.

Treat distributed ordering as uncertain

Wall timestamps from different hosts can help trace events but do not create a perfect total order when skew, latency, batching, and retry overlap.

Before implementation, I would answer:

• How much skew is possible?
• Which causal ID exists?
• Can sequence numbers help?
• What uncertainty should UI show?

The artifact is a cross-system ordering model. Its job is to expose the tradeoff early enough that design, engineering, support, or product can disagree with something concrete. The common trap is sorting logs by timestamp and declaring a causal chain; it moves uncertainty downstream and makes the final interface carry a problem the system never resolved.

For me, the useful receipt is incident timelines that distinguish observation from inference. That connects a clock-selection discipline that separates user-visible wall time from monotonic duration measurement, converts timeout chains into budgets and deadlines, scopes monotonic values to one execution, and records both intent and observed timing to an observable result instead of a process claim.

I would test this with one typical case and one boundary case. The typical case should make “How much skew is possible?” easy to answer. The boundary should force a decision about “Which causal ID exists?” and “Can sequence numbers help?.” I would record both in a cross-system ordering model, including the part that stayed unresolved after the first pass. The final check, “What uncertainty should UI show?,” is where the artifact earns its place: it either supports incident timelines that distinguish observation from inference, or it shows exactly why another iteration is needed.

Choose precision deliberately

Clock precision, coarsening, integer range, unit conversion, and floating-point representation affect both correctness and privacy and should match the decision being made.

I would use these prompts during the working review:

• Which unit is required?
• Can values overflow?
• Is sub-millisecond detail real?
• Could precision expose users?

If the team slips into mixing seconds, milliseconds, and nanoseconds in untyped numbers, the product can still look complete while its operating rule stays ambiguous. I would make a timing representation contract the shared reference and keep it small enough to update as evidence changes.

The standard is sufficient precision without false certainty or unsafe exposure. That tells me whether the decision helped the product, not merely whether the document was completed.

The working sequence is small: draft a timing representation contract, review it against “Which unit is required?,” implement the narrowest useful path, and then return with evidence for “Can values overflow?.” I would use “Is sub-millisecond detail real?” to inspect product consequence and “Could precision expose users?” to decide whether the result is stable enough to ship. This keeps mixing seconds, milliseconds, and nanoseconds in untyped numbers visible as a known risk and makes sufficient precision without false certainty or unsafe exposure the release receipt rather than a hopeful conclusion.

Observe both intent and behavior

Timing telemetry should pair wall timestamps for trace correlation with monotonic durations, queue time, deadline, remaining budget, cancellation reason, restart identity, and clock health.

I would pressure-test that decision with four questions:

• When was work intended?
• How long did it run locally?
• Where was budget spent?
• Did a clock anomaly occur?

The failure mode here is logging only start and end ISO strings. In browser, mobile, backend, distributed, and real-time systems where wall-clock adjustments, suspend and resume, process restarts, network delay, timer throttling, leap behavior, clock skew, and persistence can invalidate elapsed-time assumptions, that can hide the exact boundary a reviewer or teammate needs to understand. My working artifact would be a dual-clock timing receipt. I want it close enough to the implementation that it can change the work, not created afterward to decorate the story.

The result I would look for is diagnosis that survives skew without losing user-facing context. That is a narrower claim than saying the whole system improved, but it is also one I can verify and defend.

In practice, I would put a dual-clock timing receipt beside the question “When was work intended?” before the first implementation review. The next pass would use “How long did it run locally?” to test the boundary, then “Where was budget spent?” to expose the state most likely to be missed. I would keep “Did a clock anomaly occur?” for the release check because it asks whether the decision still holds outside the ideal path. The work is ready to move when the artifact can explain the choice and the observed result supports diagnosis that survives skew without losing user-facing context.

Test hostile time

Tests should move wall time backward and forward, freeze callbacks, suspend and resume, cross timezone changes, restart processes, inject skew and latency, exhaust budgets, cancel races, and verify user copy.

The practical review starts here:

• Can duration become negative?
• Does overdue work resume?
• Do deadlines shrink end to end?
• Can traces explain anomalies?

Those questions keep waiting for real seconds in a happy-path unit test from becoming the default. I would capture the decision in a temporal fault-injection suite, then use it while the work is still cheap to change. For time-dependent behavior that remains correct when clocks and execution contexts change, the artifact should make ownership, constraint, and next action visible without requiring a private explanation.

Success would look like evidence that timing behavior survives clocks behaving normally badly. If I cannot point to that evidence, I have a direction, not a finished decision.

The implementation move is to make a temporal fault-injection suite part of the working surface. I would use it to answer “Can duration become negative?” while scope is still flexible, and “Does overdue work resume?” before code or content becomes expensive to unwind. During QA, “Do deadlines shrink end to end?” and “Can traces explain anomalies?” become concrete checks rather than discussion prompts. That sequence turns time-dependent behavior that remains correct when clocks and execution contexts change into something the team can operate and gives me a specific outcome to report: evidence that timing behavior survives clocks behaving normally badly.

What I would show in the work

The public version needs evidence from the work itself. For this topic, the first five artifacts I would reach for are:

• a time-question classification
• a clock-choice table
• a monotonic-origin boundary note
• an end-to-end deadline budget
• a suspend-and-resume behavior table

I would not publish all five at equal weight. One should orient the reader, one should reveal the hardest tradeoff, and one should prove the result. The others can live in a downloadable note or appear as supporting frames. That edit matters because a clock-selection discipline that separates user-visible wall time from monotonic duration measurement, converts timeout chains into budgets and deadlines, scopes monotonic values to one execution, and records both intent and observed timing becomes harder to understand when every process detail is treated as equally important.

I would also show one rejected direction. The useful version is specific: which option looked attractive, which constraint made it wrong, and what evidence supported the narrower choice. That gives an engineering manager something real to question and keeps the case study from reading like the final answer was obvious from the beginning.

# intent
checkout confirmation / deadline 22:44:09.800Z
Total budget 2500ms, 200ms safety margin, caller wall instant and trace ID retained, cancellation propagates.
# local
mono start 8421.4 / end 10337.8
Elapsed 1916.4ms in process boot 6f2; queue 220, database 410, partner 1180; tab visibility not applicable.
# result
success with 383ms remaining
Wall end 22:44:09.417Z, NTP offset estimate 18ms, no restart, downstream deadline honored, user copy says completed at 5:44 PM.

Resource path

The practical follow-up I would build is a clocks-and-deadlines engineering worksheet with time question, clock choice, origin, unit, precision, suspend behavior, process boundary, timeout budget, propagated deadline, cancellation, persistence format, skew tolerance, telemetry pair, simulation cases, and user-facing copy. I am treating that as a resource backlog item, not pretending the adjacent downloads below are the same artifact. The related cards cover useful pieces of the workflow today; this specific file should only be published when its examples, fields, and instructions are complete.

The first version should stay concise: context, constraint, decision, evidence, owner, and follow-up. Its value would come from helping someone repeat this exact review, not from adding another generic PDF to the site.

Review checklist

The article-specific review questions are:

• What question is answered?
• Can time move backward?
• Which origin produced it?
• When did the budget begin?
• Does the clock include suspend?
• What survives restart?
• How much skew is possible?
• Which unit is required?
• When was work intended?
• Can duration become negative?

I would add two editorial checks before publishing: can a recruiter find the point in the first minute, and can an engineer trace at least one claim to an implementation or production receipt? If either answer is no, the article needs another edit.

Implementation notes

For time-dependent behavior that remains correct when clocks and execution contexts change, I would write the implementation note before polish. It would name the changed surface, source of truth, owner, failure boundary, and verification path. Those details prevent the principle from floating above the actual code or operational workflow.

The proof signals I care about are specific to this article:

• reconstructed deadlines without treating old monotonic values as current
• incident timelines that distinguish observation from inference
• sufficient precision without false certainty or unsafe exposure
• diagnosis that survives skew without losing user-facing context
• evidence that timing behavior survives clocks behaving normally badly

I would choose two or three of those signals for the first release rather than instrumenting everything. The strongest pair usually combines one direct behavior check with one operating check: a route and a data query, a keyboard path and a support state, a handler replay and a reconciliation result, or a migration count and a rendered screen.

The follow-up belongs in the note before shipping. It should say what remains temporary, what evidence would trigger another pass, and who owns that decision. That is how the first version stays intentionally narrow without making the boundary invisible.

Case-study packaging

I would structure the case-study version around the four visual lessons already established:

• Choose the clock from the question being answered.
• A deadline survives layers better than repeated timeouts.
• Common time values are not interchangeable.
• The timing receipt preserves question, clocks, and scope.

The opening frame explains the product pressure. The middle two show the decision moving through the system. The last frame is the receipt: what was checked, what held, and what remained unresolved. That order lets the reader move from product judgment into implementation detail without reconstructing the whole project first.

I would include one caveat tied to browser, mobile, backend, distributed, and real-time systems where wall-clock adjustments, suspend and resume, process restarts, network delay, timer throttling, leap behavior, clock skew, and persistence can invalidate elapsed-time assumptions: a data limit, rollout boundary, unsupported state, external dependency, or result that is still directional. A precise caveat makes the evidence easier to trust because it shows where the claim stops.

The final test is whether the page creates a better conversation. If the artifact helps someone ask a sharper question about product judgment, implementation detail, or release proof in a live interview, it belongs in the story.

Interview angle

In an interview, I would explain this through a clock-selection discipline that separates user-visible wall time from monotonic duration measurement, converts timeout chains into budgets and deadlines, scopes monotonic values to one execution, and records both intent and observed timing. The story should start with the product pressure, then move into the system constraint, the artifact, and the proof. That order keeps the answer grounded. It also gives the interviewer several places to go deeper: data, frontend architecture, design systems, support, migration, accessibility, or release process.

The strongest version of the answer includes a tradeoff. I want to be able to say what I chose, what I left alone, and how I knew the work helped. That is more credible than presenting every project as a clean win.

The hiring signal

A clock-selection model is a hiring signal because it shows I can reason precisely about time, browser and operating-system behavior, distributed deadlines, user communication, observability, and failure testing.

That is the level I want this site to communicate. The work should show taste, but it should also show operating judgment. It should make me look like someone who can enter a real product system, understand the messy middle, ship the useful version, and leave enough proof for the next person to trust it.