Go elapsed time: serialization loses the monotonic clock component

What it is

Go's time documentation says time.Now returns a Time with a monotonic reading. Comparisons and subtraction use monotonic readings when both operands have them, otherwise they fall back to wall time. Serialized forms omit the monotonic component because it has no meaning outside the process; several transformations also strip it. Go time package

Why it matters

An agent may persist a start timestamp and assume later subtraction has exactly the same clock semantics as a local stopwatch. That assumption crosses a process boundary. Decide whether the requirement is local elapsed time, a civil timestamp, or a deadline another process must interpret.

How to apply

• Trace where each time value originates and every transformation before comparison. Mark serialization, parsing and conversion separately from the initial capture.
• For a duration measured within one process, preserve the intended local measurement path. Store a separate wall-clock timestamp when logs or external systems need a human-readable event time.
• For persisted deadlines, specify the policy for clock changes and delayed processing. Do not describe a serialized timestamp as carrying the source process's monotonic clock.
• Propose fixtures comparing the local path with a serialization round trip. Assert the documented policy rather than relying on internal representation equality.
• Review timeout and retry calculations that mix values from different origins. Keep the remaining budget explicit when handing work to another process.

Pitfalls

Monotonic clock behavior during machine sleep is platform-dependent, as the documentation notes. A duration requirement that includes suspend time may need a different policy from one measuring active execution. Do not claim that changing a timestamp to UTC preserves every hidden clock component. These checks are a proposed design review, not an executed clock-adjustment experiment or a guarantee against every timing anomaly.