A historian expects one value per tag per instant, but reality sometimes delivers two: a backfill overlapping live data, a collector recovery replaying something already stored, or a clock adjustment landing two readings on the same time. A duplicate timestamp is that collision, and how a historian resolves it, by overwriting, rejecting, or keeping both, has real consequences for the accuracy of the archive. This page explains what a duplicate timestamp is, the different policies historians use to handle one, and how duplicates quietly corrupt averages, totals, and other aggregates if they are not resolved cleanly.
Duplicate timestamp in a historian in one line: A duplicate timestamp occurs when two values arrive for the same tag at the same timestamp, typically during backfill, collector recovery, or a clock adjustment. Historians resolve this by overwriting the existing value with the new one, rejecting the new value to keep the original, or keeping both, and the policy varies by product. Duplicates matter because unresolved or wrongly resolved collisions distort aggregates such as averages and totals that assume one value per instant.
A duplicate timestamp is simply two values claiming the same tag and the same instant, and it happens more often than the tidy model of one-value-per-time suggests. A frequent cause is backfill overlapping live data: a manual import or a recovery covers a period for which the historian already has values, so the new data collides with what is already stored. Another is collector recovery, where a reconnecting collector replays part of its buffer that had actually been delivered before the outage, presenting values the archive already holds. Each of these is a normal operational event, not an error in itself, but each produces the same underlying situation of two candidate values for one point in time.
Clock adjustments are a subtler source. If a device's clock is corrected backward, or a daylight-saving or synchronization change shifts time, the same wall-clock timestamp can be produced twice, once before the adjustment and once after, so two genuinely different readings end up carrying the same time. This is particularly insidious because both values are legitimate measurements taken moments apart, yet they collide in the archive as if they were the same instant. Clock hygiene across a distributed system reduces these collisions, but they cannot be entirely designed away, which is why the historian must have a defined response.
It helps to separate a duplicate timestamp from the related but distinct problem of out-of-order data. Out-of-order data is about values arriving in a different sequence than their timestamps imply, which challenges how the archive indexes and stores them. A duplicate timestamp is the specific case where two values share exactly the same timestamp for the same tag, forcing a decision about which value should occupy that single slot, or whether both can. They often occur together during recovery and backfill, but the duplicate is a concrete collision that needs its own resolution policy, separate from the general ordering question.
When a duplicate arrives, historians resolve it in one of a few ways, and the choice has real consequences. The first is overwrite, often described as last-write-wins or an upsert: the new value replaces whatever was already stored at that timestamp. This is convenient for corrections, because a backfill of better data can supersede an earlier placeholder, but it is dangerous when the incoming duplicate is actually worse, such as a recovery replaying stale data over a good value. Overwrite trusts the newest arrival, which is only right if the newest arrival is genuinely the more correct value, and that is not always the case.
The second policy is reject, where the historian keeps the value it already has and refuses the duplicate. This protects an existing good value from being clobbered by a late or replayed arrival, which is often the safer default during recovery, but it can also block a legitimate correction from landing. The third is keep-both, where the historian stores multiple values at the same timestamp, deferring the conflict rather than resolving it. Keeping both preserves all the information, but it pushes the ambiguity downstream to whatever reads the data, which then has to decide which of the coincident values to use, and can produce surprising results if a query or aggregate silently picks one or counts both.
Which policy a given historian uses, and whether it can be configured, is an important thing to know about your specific archive, because it determines what actually happens when backfill and recovery inevitably produce collisions. Some historians default to overwrite, some to reject, and some allow the behaviour to be set per tag or per import. The practical guidance is to know your historian's policy, choose it deliberately where you can, and resolve conflicts in the source data before import when possible, so that a collision is settled by a considered decision rather than by whatever the archive happens to do with the two values that showed up.
The reason duplicate timestamps deserve attention is that they quietly damage the calculated numbers people actually rely on. Aggregates such as averages, totals, minimums, and maximums are computed on the assumption that there is one value per instant, and duplicates break that assumption in ways that depend on how they were resolved. If a historian kept both values at a timestamp, a total might double-count that point, and an average might be pulled toward the duplicated reading; if it overwrote with a worse value, the aggregate reflects the wrong number entirely. The corruption is rarely obvious in the raw trend, but it shows up as a total that does not reconcile or an average that is subtly off, which is exactly the kind of error that undermines trust in reporting.
This makes duplicate resolution part of archive integrity, not a mere technicality. A historian that resolves duplicates predictably and visibly, and that flags when a collision occurred and how it was settled, gives operators a chance to catch a bad resolution before it flows into a report. One that silently keeps both or silently overwrites leaves the corruption in place, to be discovered, if ever, when someone notices a number that will not add up. Treating collisions as events worth logging, rather than as invisible internal behaviour, is what keeps the aggregates defensible.
In a SCADA and cloud monitoring context, duplicate timestamps are especially likely because the same conditions that make distributed data valuable, remote collectors, buffered recovery, manual backfill, and imperfect clock synchronization across many sites, are exactly the conditions that generate collisions. A platform such as Merobix has to resolve these deterministically and make the resolution visible, so that a recovery replaying already-stored data, or a backfill overlapping live values, does not silently corrupt the totals and averages an operator reports from. Knowing that duplicates are handled by a defined, observable policy rather than by chance is part of what lets a team trust aggregates computed over data gathered from many sites and reconciled through backfill and recovery.
The common causes are backfill overlapping data the archive already holds, collector recovery replaying part of a buffer that was actually delivered before an outage, and clock adjustments that produce the same wall-clock time twice. Each is a normal operational event rather than an error in itself, but each creates two candidate values for one point in time, forcing the historian to decide how to resolve the collision.
It uses one of a few policies: overwrite, where the new value replaces the stored one, often called last-write-wins; reject, where it keeps the existing value and refuses the duplicate; or keep-both, where it stores multiple values at that timestamp and defers the conflict to whatever reads the data. The behaviour varies by product and is sometimes configurable, so it is important to know and deliberately choose your historian's policy.
Aggregates such as averages and totals assume one value per instant, so duplicates break that assumption depending on how they were resolved. Keeping both can make a total double-count a point and pull an average toward the duplicated reading, while overwriting with a worse value makes the aggregate reflect the wrong number. The error is rarely visible in the raw trend but shows up as a total that does not reconcile or an average that is subtly off.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.