Global – October 29, 2026 -- Historians that stamp MQTT messages with broker arrival time can display an old pressure reading as a new process condition, distorting aggregates, alarms and event order during outage replays.
Plain MQTT defines no process-time field
MQTT specifies only the transport of an application message. It prescribes no timestamp field, industrial clock model or time semantics. The publisher's application contract decides whether a payload carries a time, in what format and with what quality.
OPC UA's SourceTimestamp and ServerTimestamp concepts do not carry over to ordinary MQTT payloads. Broker receipt time and connector receipt time are useful operational observations, but they do not prove when a machine produced a measurement.
In an illustrative payload for asset compressor-12, an event_time of 2026-10-27T08:15:04.125Z alongside a discharge_pressure_kpa of 742.6 is valid history only if the gateway defines it as observation time and its clock is trustworthy. A field named ts is not enough: unit, timezone, source and restart behavior must be agreed and tested.
Source event time should be the record time, with ingestion time kept separately
Where the source can supply a valid value, source event time gives a truthful process chronology. A separately preserved ingestion or receipt time lets engineers distinguish a late delivery from a late event.
Devices without reliable clocks, payloads carrying only a sequence number, and gateways that sample without event timestamps are valid exceptions. In those cases, a documented collection or ingestion time should be used rather than an invented source time, and downstream users must know the record reflects collector observation.
Validation rules must cover timezone, epoch unit and clock drift
The source-data contract should require ISO 8601 values with Z or an explicit offset. Integer epochs must declare seconds, milliseconds, microseconds or nanoseconds, because the unit cannot be inferred from digit count. Each source class needs defined future-skew and stale-data limits, and gateways need clock-health monitoring and resynchronization after replacement, reboot or loss of time service. Null, malformed or out-of-range times must be rejected, archived, flagged or replaced with arrival time under an explicit policy.
In TDengine, the timestamp is the primary key for time-series data, and the database precision, which defaults to milliseconds, determines how integer timestamps are interpreted. A millisecond payload cannot safely be read as microseconds or nanoseconds simply because a connector accepts it.
Late, replayed and duplicate records require explicit handling
Network interruption, local buffering, broker queues and retry can all delay a message without making the measurement newer. Queries sorted by event time show the process correctly, while views based on ingestion order expose the backlog. One timestamp cannot answer both questions without a declared compromise.
A retransmitted message can carry the same source time as the original. Stable sequence numbers or event identifiers should be retained, and a duplicate policy defined. MQTT QoS and broker receipt validate neither the source clock nor the business meaning of the time field.
Controlled late-data tests define the pass condition
The recommended test publishes a small series with known event times and a source identifier, delays one message until after a newer measurement, and replays a previous message. It also includes an intentionally malformed or wrong-unit timestamp. Queries by event time are then checked against separately inspected arrival evidence, along with handling of duplicates, null time, stale data and future time.
Passing requires more than a row per message: the historian must explain process sequence accurately, expose transport delay when needed, and handle invalid time under an agreed rule. Each measurement class should document its time owner, format, precision, timezone, allowable clock drift, fallback behavior and any additional arrival-time field, with a review whenever a PLC, edge gateway, firmware version or broker route changes.