The Case for Strictly Monotonic Time

Monotonic time serves as a foundational abstraction in systems programming, providing a reliable measure of elapsed duration that's immune to clock adjustments, timezone changes, or system sleep events. The standard implementation pattern involves querying the operating system's monotonic clock while applying an in-process guard to prevent any potential non-monotonic behavior from the OS. This guard typically ensures that each subsequent reading is at least as large as the previous one, but allows equality.

The conventional approach looks something like this: when requesting the current time, we ask the OS for its monotonic reading, then compare it against our stored guard value. If the OS reading is smaller (which shouldn't happen but sometimes does due to kernel bugs or hardware quirks), we use the guard value instead. We then update the guard to this new value and return it. The key characteristic here is that the guard allows equality - if the OS returns the same value twice, we accept it.

However, this equality allowance introduces subtle ambiguity in temporal reasoning. When we compare two time instances and find them equal, we cannot determine whether they represent the same moment in time or two distinct moments that happened to have identical timestamps. This ambiguity becomes particularly problematic in concurrent systems where event ordering matters, in debugging scenarios where we're trying to understand race conditions, or in distributed systems where we need to establish causal relationships between events.

Consider a scenario where we're tracking the execution order of asynchronous operations. If we record timestamps for start and end events, and find that two operations appear to have identical timestamps, we cannot definitively say whether they executed sequentially (with one completing before the other started) or concurrently. The <= comparison allows both possibilities, leaving us with uncertainty about the actual execution order.

The proposed refinement is deceptively simple: instead of clamping to max(t_raw, clock.guard), we clamp to max(t_raw, clock.guard + 1ns). This small change enforces strict monotonicity - every new time reading must be strictly greater than the previous one. The implementation ensures that even if the OS returns the same value multiple times, we increment it by at least one nanosecond to maintain strict ordering.

The implications of this change are profound. With strictly monotonic time, any two time instances that are numerically equal must have been derived from the exact same call to now(). This eliminates the ambiguity entirely. When we see past <= present, we can strengthen it to past < present with confidence, because equality now carries semantic meaning - it indicates the same temporal origin.

This strengthening of assertions has practical benefits throughout the codebase. In state machines, we can assert that transitions occur in strictly increasing time order. In caching systems, we can more reliably determine whether cached data is stale. In debugging, we can more accurately reconstruct the sequence of events leading to a bug. The change transforms time from a partially ordered set into a totally ordered set with respect to the operations we perform.

The constraint, of course, is resolution. If we increment by one nanosecond each time, we need sufficient resolution to avoid running into the future. Modern systems typically provide nanosecond precision for monotonic clocks, which gives us ample headroom. Even at a million calls per second, we'd only advance by one millisecond per second - negligible compared to the typical operating system clock resolution.

There are trade-offs to consider. The strict monotonicity guarantee comes at the cost of slightly altering the temporal measurements. Each reading is potentially offset by up to a few nanoseconds from the actual OS reading. For most applications - performance measurement, timeout handling, rate limiting - this offset is irrelevant. However, for applications requiring precise alignment with OS-reported times (such as certain types of synchronization with external systems), this could matter.

The approach also assumes that the guard value itself doesn't overflow or wrap around, which is reasonable given the 64-bit nanosecond counters typically used and the extremely long timescales involved. A 64-bit nanosecond counter would overflow after approximately 584 years, far exceeding any practical system lifetime.

From a philosophical perspective, this refinement represents a move toward making time a more precise tool for reasoning about causality. In distributed systems theory, we often distinguish between logical clocks (which capture causality) and physical clocks (which capture wall-clock time). Strictly monotonic time bridges this gap somewhat, providing a physical clock that also guarantees a total ordering of local events.

The implementation pattern also suggests broader implications for how we design temporal abstractions. Rather than accepting the OS's promise of monotonicity at face value, we're adding an additional layer of enforcement within our own code. This defensive programming approach acknowledges that while the OS contract is generally reliable, the long tail of edge cases (documented in issues like Rust's PR #56988) justifies the extra protection.

For systems programmers considering this approach, the migration path is straightforward. The change is localized to the time retrieval function, and the strengthened assertions can be adopted incrementally. The backward compatibility is maintained since strictly_monotonic_time >= monotonic_time always holds.

Ultimately, this refinement exemplifies how small, thoughtful adjustments to foundational abstractions can yield disproportionate benefits in code clarity and reliability. By making time strictly monotonic, we eliminate a class of temporal ambiguities that have long plagued concurrent and distributed systems, making our programs easier to reason about and less prone to subtle timing-related bugs.