.png)
Offline Logger Timestamps: Budget Clock Uncertainty During Holdover
A logger can keep collecting measurements while disconnected from its time reference, yet the timestamps become progressively less certain. A neat one-second display does not prove one-second accuracy. Define the allowable timing uncertainty, use a justified clock-drift assumption and retain evidence of synchronisation loss and recovery.
Original conceptual illustration; not a specific product, live software screen or customer installation.
Key takeaways
Timestamp resolution and timestamp accuracy are different properties.
Holdover uncertainty depends on the clock and elapsed offline time.
Do not silently rewrite historical event times after reconnection.
1. Define what the timestamp means
Document whether the record time represents acquisition at the instrument, collection at a gateway or receipt by a remote service. These events can occur at different times even when every clock is synchronised. Communications delay is not automatically oscillator drift.
Record the time source, synchronisation method and evidence available when it is lost. Some devices expose synchronisation status or last successful update; others provide much less information. Check the exact logger and firmware rather than assuming those diagnostic fields exist.
Also distinguish display resolution from accuracy. A timestamp printed to milliseconds may still have substantial uncertainty. Choose acceptance limits from the application’s event-ordering or reporting needs, not the number of decimal places on a screen.
2. Use a justified holdover model
RFC 5905 describes uncertainty growth with elapsed time in its NTP dispersion model. The engineering lesson is that an unchanged clock display is not proof of unchanged timing confidence. Its protocol parameters must not be substituted for a particular logger’s oscillator specification.
For a simple conservative planning model, start with an established uncertainty at the last trusted synchronisation and add a justified drift allowance over the offline interval. State the assumptions and units. Temperature, ageing, power transitions and implementation details may require a more complete budget.
If the manufacturer provides no usable holdover specification, identify that gap. A short observation can inform an investigation, but it does not establish worst-case behaviour across the full environmental range. Ask for suitable documented evidence before promising a timing bound.
3. A hypothetical six-hour budget
Assume an initial uncertainty allowance of 0.20 seconds and a justified drift allowance of 20 parts per million for this example only. Six hours is 21,600 seconds. The additional allowance is 21,600 × 20 ÷ 1,000,000 = 0.432 seconds, giving a simple combined planning allowance of 0.632 seconds.
These assumed numbers are not specifications for any ProSense product. Nor is this simple addition a complete metrological uncertainty evaluation. Its purpose is to make the holdover requirement explicit enough to challenge the assumptions and compare them with the application’s tolerance.
If the allowable event-ordering margin were smaller than this planning allowance, the team would need better time evidence, a shorter permitted holdover period or another suitable design. Do not increase confidence merely by rounding 0.632 to fewer displayed digits.
Original explanatory diagram. Hypothetical values and proposed checks are described in the text; this is not a product specification or field result.
4. Plan reconnection and historical evidence
Ask how the device behaves when time becomes available again: it may adjust its clock in a way that affects subsequent timestamps. Verify the documented behaviour and test it in an isolated environment. Never assume all loggers correct time identically.
Keep original acquisition records and any correction or interpretation as separately traceable information. If a historical timeline is reconstructed, record the method, affected interval and uncertainty. An unexplained overwrite can make an event sequence appear more certain than the evidence supports.
Use UTC or another explicitly defined time representation for exchange, while retaining required local reporting context. Calendar boundaries and daylight saving are a separate design question; correct timezone conversion cannot remove an uncertain source clock.
Define acquisition, gateway and receipt times separately.
Establish initial timing evidence and a justified drift allowance.
Calculate a documented holdover budget for the required outage.
Test synchronisation loss, reconnection and historical traceability.
5. Commission the timing requirement
Run an approved offline test long enough to examine the agreed application requirement, recording trusted reference comparisons, environment and device state. Include power interruption only where it is safe and explicitly part of the test plan. Preserve raw comparisons and configuration revisions.
Common mistakes include using a protocol’s default drift allowance as a device guarantee, conflating network latency with acquisition-time accuracy and ignoring the clock after power loss. Another is merging events from multiple devices without comparing their separate timing uncertainties.
For the next logging project, give ProSense Solutions the required event resolution, maximum disconnected period and acceptable uncertainty. Include the proposed equipment manuals and recovery behaviour. That provides a practical basis for selecting and validating a logging architecture without promising unsupported timestamp performance.
Related guide and project resources
Technical references
Need help with your application?
Send the relevant point list, equipment documentation and a sanitised example of the behaviour you need to verify. Confirm the available functions and integration requirements for the exact equipment and deployment.
