.png)
Clock Corrected During a Test? Measure Elapsed Time on the Right Clock
A monitoring test records an end timestamp earlier than its start, or a ten-second operation appears to take several minutes after a clock correction. The operation and the reporting clock may be answering different questions. Use an appropriate elapsed-time clock for local duration checks, while retaining UTC event timestamps for correlation and audit.
Original conceptual illustration; not a specific product, live software screen or customer installation.
Key takeaways
UTC identifies when an event was recorded; elapsed time measures a duration.
A monotonic reference is not a shared timestamp between devices.
Test clock corrections and restart boundaries separately.
1. Name the timing question
Start with the acceptance requirement. Is the project checking how long one local request waited, when an event occurred across several assets, or how long a remote sensor was offline? Each question needs a defined start event, finish event and clock domain.
Wall-clock timestamps are useful for correlating records and presenting an event in its calendar context. They can be corrected by the operating system or administrator. Subtracting two such timestamps without considering corrections can misrepresent the duration of a local operation.
A monotonic clock is intended for differences within its supported reference domain. Python’s time documentation states that its monotonic clock cannot go backwards and is unaffected by system clock updates; only differences between readings are meaningful. Confirm the corresponding guarantees for the actual controller, gateway or runtime.
2. Keep two useful records
For a local communications test, record UTC start and finish timestamps for correlation and a separate elapsed duration from the selected monotonic source. Include the runtime and host identity. The two records explain different aspects of the same attempt.
Do not send a bare monotonic value from one gateway and subtract it from a value produced by another. Their origins and lifecycles need not match. Cross-device latency measurement requires a separately justified clock-synchronisation and uncertainty method.
Also distinguish elapsed time from CPU execution time. A request that spends most of its life waiting for a remote response still consumes elapsed time. A processor-time measurement can therefore understate the waiting experience that the operator or timeout requirement cares about.
3. Work through a clock-step example
In a hypothetical bench test, a read starts at wall-clock 10:00:00. Three seconds later, the wall clock is corrected backwards by sixty seconds. The response arrives after a total of eight real elapsed seconds, at a displayed wall time of 09:59:08.
Subtracting the two displayed timestamps gives minus fifty-two seconds. A suitable monotonic difference over the same uninterrupted run gives eight seconds. These invented values illustrate a measurement error; they are not a benchmark or a promised response time.
Keep the wall-clock correction visible in the test evidence. Do not rewrite the end timestamp to make the subtraction positive. Investigate whether logging order, expiry decisions or other consumers also depended on the corrected clock.
Original explanatory diagram. Examples are hypothetical; verify the actual equipment, interface contract and project requirements.
4. Define restart and suspend behaviour
A duration measurement must have a valid lifecycle. Establish what happens if the process restarts, the device reboots or the operating system suspends between readings. The selected clock’s documentation must determine whether suspended time is included.
A persisted monotonic start value may not be meaningful after a reboot. Define a new measurement boundary or an explicit recovery state instead of silently comparing incompatible references. Record a boot or run identifier where the design supports one.
For an expiry that must survive a restart, discuss the requirement separately with the system designer. Persisted calendar deadlines, remaining durations and trusted recovery time each have assumptions. A generic stopwatch pattern is not a complete recovery policy.
State the two events and whether the requirement is duration or event correlation.
Select and document the clock source and lifecycle.
Retain UTC records alongside elapsed durations.
Test correction, restart and suspend cases within an isolated approved scope.
5. Build an isolated acceptance test
Use a test environment that cannot affect production control, certificates, scheduled jobs or other services when its clock changes. Have the responsible integrator arrange the clock correction through an approved method. Do not alter a production controller’s time simply to demonstrate this article.
Test an ordinary interval, a forward wall-clock correction, a backward correction and the agreed restart or suspend case. Compare the measured duration against an independent suitable reference within the project’s uncertainty allowance.
For handover, retain the clock source, runtime version, lifecycle rules, raw event records and measured durations. ProSense Solutions can discuss a timing requirement using that evidence. Confirm the exact equipment’s facilities rather than assuming every PLC or gateway exposes the same clock API.
Related guide and project resources
Need help with your application?
Send the relevant equipment documentation, field definitions and a sanitised example of the behaviour you need to verify. Confirm the available functions and integration requirements for the exact equipment and deployment.
