Global – October 29, 2026 -- Choosing the wrong OPC UA timestamp can reorder events, hide network delay or place valid data outside the historian query window, so most process analysis should use a trustworthy SourceTimestamp as event time and keep collector receipt time as a separate field.
SourceTimestamp stays fixed as data passes through servers
The OPC UA specification defines SourceTimestamp as the time a data source applies to a value, ideally the last change of the value or status, generated as close to the source as possible. It does not change when the value passes through another OPC UA server. That makes it the best fit for sequence-of-events work, batch analysis and calculations tied to when the process changed.
It is not automatically accurate. A PLC, gateway or source server can have a drifting or wrongly set clock, and the timestamp can be null. Source time should be compared with a trusted clock and the offset monitored over time.
ServerTimestamp and receipt time answer different questions
Each OPC UA server applies its own ServerTimestamp while preserving the original SourceTimestamp. A large gap between source and server time can indicate clock drift, upstream buffering, an incorrect clock or real transport delay, so it is a diagnostic signal rather than a latency measure.
Collector timestamps for request and receipt are not OPC UA DataValue timestamps defined by the standard. They support latency and backlog monitoring, but neither proves when the process changed. If an outage delays a source event by 20 minutes, stamping it only with receipt time makes the late event look new and distorts trends and calculations.
Late and duplicate records need a defined policy
Store-and-forward recovery and server-side history can deliver old source events after newer ones. Queries should order by event time. Streaming calculations and windowed aggregates need a rule for late arrivals, such as recalculating prior windows or flagging records for reconciliation.
Reconnect or backfill can resend records. Point identity, event time, value, quality and an available event identifier can separate duplicates from legitimate observations.
UTC should stay in storage and be localized only on display
OPC UA conveys time in UTC. Adding a fixed offset before storage causes problems at daylight-saving transitions and across sites in different zones, and it can hide a clock configuration error. Site time zone can be stored as metadata, and implausible timestamps should be flagged rather than silently replaced.
TDengine offers three timestamp fields for OPC UA points
The TDengine TSDB-Enterprise OPC UA connector documentation lists origin_ts, request_ts and received_ts. The selected value becomes the TDengine timestamp column. In CSV mapping, these correspond to the source timestamp, the time taosX issued the request and the time taosX received the value. The documentation does not describe request_ts or received_ts as OPC UA ServerTimestamp fields.
For process history, origin_ts is the starting point once the source clock is confirmed sound. received_ts fits cases where ingestion chronology is the intended time axis or source timestamps are unusable. request_ts may align polled observations with the collection cycle. Where the mapping allows multiple timestamp columns, an additional request or receipt timestamp should be kept for troubleshooting. Late records, equal timestamps, null source times and clock drift should be tested on representative points before rollout.
A five-question review belongs in the historian data contract
The review asks which system owns each timestamp and whether its clock is synchronized, and whether the application needs process, observation or arrival time. It also asks what happens when source time is null, stale or implausible, whether the historian and downstream calculations handle late records, and whether engineers can compare source and receipt time during an outage investigation.