Every value that reaches a SCADA server can carry two different times: the moment the event actually happened at the device, and the moment the server received it. The first is the source timestamp, the second is the server timestamp, and the gap between them is usually tiny but occasionally enormous. Understanding which is which, and which one to trust, is the difference between a historian that records when things happened and one that merely records when it heard about them. This guide draws the line clearly, explains why the gap matters for buffered and store-and-forward data, and covers how protocols expose both times.
Source vs Server Timestamp in one line: A source timestamp is the time captured at the device or edge when the event actually occurred, also called event time; a server timestamp is the time the SCADA server received and logged the value, also called receive time. They match when communications are fast, but delay, buffering, or store-and-forward can open a large gap, and for accurate history the source timestamp is the one to trust.
The distinction is about where on the data path the clock is read. A source timestamp is applied at the origin, by the device, edge unit, RTU, or PLC, at the instant the value was measured or the event occurred. It answers the question of when the process was actually in that state. A server timestamp is applied at the other end, by the SCADA server or collector, at the instant the value arrived and was logged. It answers a different question: when the system first became aware of the value. These are two genuinely different moments, and conflating them is a common source of confusion.
In everyday operation with a healthy, fast link, the two are nearly indistinguishable. A value is measured, transmitted, and received within a fraction of a second, so the source and server timestamps agree closely enough that it rarely matters which one you look at. This is why the distinction is easy to overlook; for the common case it makes no visible difference, and a system that quietly uses server time can appear to work perfectly well right up until the moment the two times diverge.
There is also a subtler trap on the source side involving polling. When a server polls a device on a schedule, the value it reads is stamped at the poll, but the change it reports may have happened at any point since the previous poll. So a poll-time source timestamp is more accurate than a server-receive timestamp, but it can still lag the true event time by up to the polling interval. The most accurate arrangement is for the device itself to detect the change and stamp it at the exact instant it occurred, which is what genuine event-time capture at the edge provides.
The gap between source and server time stops being academic the instant communications are not instant. Consider a device that loses its link, buffers hours of readings locally, and forwards them all when the connection returns. If those readings are logged with server time, every one of them is stamped at the reconnect moment, collapsing hours of history into a single false spike at the instant the backlog arrived. If they carry source timestamps from when each value was actually measured, every reading drops back into its true position and the outage becomes a recoverable gap rather than a fabrication. Store-and-forward only works because the data is source-timestamped.
Sequence-of-events analysis raises the stakes even higher. When a cascade of alarms trips across a facility, the exact order and the sub-second spacing between events is what reveals cause and effect. Server timestamps cannot preserve that, because the delays of transmission and processing reorder and smear the events by more than the intervals being measured, so the recorded order can differ from what actually happened. Only source timestamps, captured at the device at the true instant of each event, keep the real order intact all the way to the historian.
The same reasoning governs comparisons across sites. To line up an event at one location against a related event at another, both must be anchored to when they truly happened, on synchronized clocks, which means both must be source-timestamped. If one is source-stamped and the other server-stamped, the comparison mixes event time with receive time and becomes meaningless even though each individual value looks fine. Consistent source timestamping, on clocks that agree, is what makes a multi-site timeline trustworthy.
For the historical record, the source timestamp is the one to trust, because it reflects when the process was actually in a given state rather than when a server happened to hear about it. Protocols built for industrial data make this explicit. In OPC, for example, a value carries a distinct source time and server time, precisely so a client can tell when the underlying data was true apart from when the server updated it. A historian that records the source timestamp preserves the real history; one that stamps everything on receipt fabricates a history built on network timing, which looks convincing until any delay appears.
The important caveat is that a source timestamp is only as trustworthy as the clock that produced it. A device with a drifting or misconfigured clock stamps its data at the wrong time, and because that stamp is authoritative, the historian trusts the wrong time completely, which can be worse than an honest receive time. This is why source timestamping and clock synchronization go hand in hand: the source timestamp is the right one to keep, but only if the field clocks that generate it are disciplined to a common reference so their times actually mean what they claim.
The robust pattern, used by well-designed platforms including Merobix, is to preserve the source timestamp as the authoritative record while also retaining the server or receive time for diagnostics. The source time places each value at its true moment on the timeline, so buffered data and events land correctly, while the server time remains available to measure delay and to catch a device whose clock has clearly gone wrong. Keeping both, but trusting the source, gives a historian a timeline that reflects when things actually happened in the field, with the means to detect the occasional field clock that lies about it.
For representing when an event actually occurred, yes, provided the device's clock is correct. The source timestamp is captured at the origin when the value was true, while the server timestamp only records when the value arrived, which can lag by anything from a fraction of a second to hours during buffering. The one exception is that a source timestamp from a drifting or wrong field clock can be misleadingly authoritative, which is why source timestamping depends on good clock synchronization.
So a client can distinguish when the underlying data was actually true from when the server last updated its copy. The source time reflects the event at the device or process, while the server time reflects the server's own handling of the value. Keeping both lets applications trust the source time for history while using the server time to understand delay and detect stale or problematic updates.
The buffered readings all get stamped at the moment they arrived rather than when they were measured, so an entire outage worth of data collapses onto the reconnect instant as a single false spike. The true shape of what happened during the outage is lost, and the timeline is distorted. Using the source timestamp instead returns each reading to its real position and turns the outage into a recoverable gap.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.