Telemetry timestamps, source time and arrival time

A sensor reading can carry up to three times: when the value was measured, when a gateway collected it, and when the receiving system received it. Under normal conditions they are seconds apart, and it seems not to matter which one you store. After a network outage they can be hours apart, and a system that stored the wrong one puts yesterday's load in today's interval.

This guide is part of the data quality and delivery series.

Three times

Protocols differ in what they carry:

• OPC UA returns a SourceTimestamp and a ServerTimestamp with each value, as Part 4 of the specification defines.
• IEC 60870-5 types with a time tag carry the outstation's time; others carry none.
• Modbus carries no time at all. The collection time is the best available.
• MQTT carries no measurement time. Put it in the payload.

Record, for each point, which time it carries and where that time came from.

Rules that prevent most errors

1. Use UTC, or an explicit offset. RFC 3339 defines a format such as 2026-09-23T14:05:00Z or 2026-09-23T15:05:00+01:00. Local time without an offset is ambiguous when clocks go back each autumn: the hour from 01:00 to 02:00 happens twice.
2. Label intervals consistently. State whether a 15-minute value is labelled by the start or the end of its interval, and use the same rule in every system. A mismatch shifts every value by one interval, and a demand peak moves to the wrong quarter-hour.
3. Synchronise clocks. Every device that sets a source time needs a reliable time source. Record which one, and alarm when a device's clock drifts or loses synchronisation.
4. Never overwrite source time with arrival time. When a reading has no source time, store the collection time and mark it as such.

Late data after an outage

When a link recovers, a gateway that buffered readings sends them late. The receiver must place each one by its source time:

The store-and-forward guide shows how long such a backlog takes to drain. Check what the receiving platform does with late data. Some accept it only within a window; some recalculate totals and alarms that have already run; some ignore it. Agree the behaviour, and test it with a planned outage.

Duplicates

Retries mean that the same reading can arrive twice: once before a failure was noticed, and again from the retry queue. Give every reading an identity, such as the point identifier plus the source time, so that the receiver keeps one copy. Without that identity, a replayed interval doubles its energy. The MQTT QoS guide explains why at-least-once delivery produces duplicates.

A value that has not changed

A steady value is not a stale value, and an old source time does not always mean the source has stopped. An OPC UA server can keep the SourceTimestamp of a value that has not changed, while it confirms the value with a new ServerTimestamp. Judge freshness by the time of the last message received from the source, not by the time of the last change. The stale data guide explains how to decide when a point is stale.

Specify timestamps in a project

For each point, record:

• which time the reading carries, and which component sets it;
• the time zone, and the clock source of that component;
• for interval values, whether the label is the start or the end;
• the identity used to remove duplicates;
• how the receiver handles readings that arrive late, and how late is too late.

Timestamps with Edge

Edge on the ZGW-20 Gateway puts a timestamp on every reading and sends it with the reading to each destination. When an upstream destination fails and Edge replays the readings later, they keep their original timestamps. For polled protocols such as Modbus, BACnet and OPC UA, the timestamp is the time of the read. Check that the receiving platform files late readings by that time.