OPC UA can attach more than one time to the same value. Those timestamps answer different questions. Choosing one without defining its meaning can reorder events, hide network delay, or place valid data outside the historian query window.
For most process analysis, use a trustworthy SourceTimestamp as the event time. Preserve a collector receipt timestamp as a separate field when the ingestion path supports it. Use server, request, or receipt time as the primary historian time only when that better matches the application or the source clock cannot be trusted.
SourceTimestamp means time at the source
The OPC UA SourceTimestamp represents the time applied to a value by its data source. The specification says it should describe the last change of the value or status and should be generated as close to the source as possible. Once assigned to that value instance, it does not change as the value passes through another OPC UA server.
This timestamp is usually the best fit for sequence-of-events work, batch analysis, and calculations that depend on when the process changed. It keeps the event on the process timeline even if the message reaches the historian late.
SourceTimestamp is not automatically accurate. A PLC, gateway, or source server may have a drifting clock, a wrong time setting, or poor synchronization with other sites. The timestamp may also be null when the source cannot provide it. Before treating source time as authoritative, compare it with a trusted clock and monitor the offset over time.
ServerTimestamp means time known by the OPC UA server
The ServerTimestamp reflects when the OPC UA server received a value or knew it to be accurate. If one OPC UA server receives values from another, each server applies its own ServerTimestamp while preserving the original SourceTimestamp.
Server time can help diagnose the segment between the source and the server. It may also be useful when the source clock is unavailable but the server clock is controlled. It is not a substitute for source time when the question is exactly when the physical process changed.
The two clocks may not be synchronized. A large difference can mean device clock drift, upstream buffering, an incorrect clock, or real transport delay. Treat the difference as a diagnostic signal, not automatically as latency.
Collection time adds another clock
Many collectors also record when they requested or received a value. These are collector timestamps, not OPC UA DataValue timestamps defined by the standard.
Receipt time answers, “When did this collector see the record?” It supports latency and backlog monitoring. Request time can identify the scheduled collection cycle that produced an observation.
Neither time 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. This can distort trends and calculations even though the database write itself is successful.
Choose the primary time from the use case
| Historian use | Preferred primary time | Reason |
|---|---|---|
| Process trends and batch reconstruction | SourceTimestamp | Preserves the source event timeline |
| Sequence of events across devices | SourceTimestamp, with synchronized clocks | Ordering depends on comparable source clocks |
| Ingestion latency and pipeline monitoring | Receipt time | Measures when the collector received the record |
| Regular polling snapshot | Request or receipt time may fit | Represents the observation cycle when source change time is absent or stale |
| Source with an unreliable clock | Controlled server or receipt time | Avoids using a known bad source time as the index |
If the system can store more than one timestamp, keep source time and receipt time. One supports process meaning; the other supports delivery diagnostics. Server time can add value when the source-to-server segment needs separate analysis.
Names such as source_ts, server_ts, and received_ts make the semantics visible to query authors. Document which field is primary and what happens when it is null or implausible.
Plan for late and out-of-order data
Store-and-forward recovery and server-side history can deliver old source events after newer ones. A historian that uses SourceTimestamp should accept that such records are late or out of arrival order.
This is expected behavior, not necessarily corrupt data. Queries should order by event time. Streaming calculations and windowed aggregates need a policy for late arrivals, such as recalculating prior windows or flagging records for reconciliation.
Also define duplicate handling because reconnect or backfill can resend a record. Point identity, event time, value, quality, and an available event identifier can help distinguish duplicates from legitimate observations.
For more on recovering and validating historical data after network interruptions, see our guide to preventing OPC UA data gaps.
Keep UTC in storage and localize at display time
OPC UA conveys time values in UTC, while the client handles conversion to local time. Keep UTC through collection and historian storage. Convert it only in dashboards, reports, or user interfaces.
Adding a fixed offset before storage creates trouble at daylight-saving transitions and when data spans sites in different zones. It can also hide a clock configuration error. Store the site time zone as metadata if operators need local views, but do not rewrite the event itself as an ambiguous local timestamp.
UTC describes the time scale, not the accuracy of each clock. Monitor clock status and source-to-receipt offset. Flag implausible timestamps rather than silently replacing them.
Mapping OPC UA time in TDengine
The current TDengine TSDB-Enterprise OPC UA connector documentation offers three timestamp choices for a point: origin_ts, request_ts, and received_ts. The selected value becomes the TDengine timestamp column. In CSV mapping, the corresponding columns are the source timestamp, the time taosX issued the request, and the time taosX received the value.
TDengine’s origin_ts is the connector’s original OPC point timestamp. The documentation does not describe request_ts or received_ts as OPC UA ServerTimestamp fields. Keep that product mapping separate from the OPC UA standard’s SourceTimestamp and ServerTimestamp terminology.
For process history in a time-series database, start with origin_ts only after confirming that the source clock is sound. Choose received_ts when ingestion chronology is the intended time axis or when source timestamps are unusable. For polled observations, request_ts may align the row with the collection cycle.
Where the mapping format allows multiple timestamp columns, retain an additional request or receipt timestamp for troubleshooting. Confirm which configured field becomes the primary timestamp, then test late records, equal timestamps, null source times, and clock drift with representative points before rollout.
A five-question timestamp review
- Which system owns each timestamp, and is its clock synchronized?
- Does the application need process time, observation time, or arrival time?
- What happens when source time is null, stale, or implausible?
- Can the historian and downstream calculations handle late records?
- Can an engineer compare source and receipt time during an outage investigation?
The answer should be part of the historian data contract. Timestamp choice is not a connector default to accept blindly. It determines what every trend, aggregate, and event sequence will mean.
