One machine's clock is ninety seconds ahead of the rest of the plant. Which of your numbers are wrong, and how would you have found out?

Nothing errors, which is the problem

A ninety-second offset produces no exception anywhere. Every write succeeds, every query returns rows, every chart renders. What you get instead is a set of numbers that are individually plausible and quietly wrong, and a family of correlations that almost work — which is worse than a break, because a break gets fixed on the day it appears and this gets built on for a year.

The reason it spreads so far is that almost every question worth asking in a plant is a join on time. This reading against that work order. This vibration against that batch phase. This stop against the scrap it produced. The join key is the thing that is wrong, so the damage is not localised to one metric.

Attribution: readings land on the wrong unit of work

The first casualty is anything that assigns a reading to a context, because context has boundaries in time. Suppose the line changes over every twenty minutes, so context boundaries are 1,200 seconds apart. Every reading whose true time is within ninety seconds of a boundary gets attributed to the neighbouring interval, which is 90 of every 1,200 seconds, or 7.5% of all readings.

That is not a rounding error in the analyses that consume it. Seven and a half per cent of your process data is attributed to the wrong product, the wrong work order and the wrong operator, and it is concentrated exactly where the process is least stable — start-up and changeover — so the misattributed readings are also the least representative ones. A comparison of two products' process signatures is now contaminated with each other's start-up transients, and the effect is systematic rather than random, so more data does not average it away.

Durations: the error goes straight into the metric

Attribution errors are diffuse. Duration errors are direct, and they are the ones that reach a report someone acts on.

A stop duration computed by subtracting a start event from an end event is only correct if both timestamps came from the same clock. They frequently do not: a station reports its own stop, while the resumption is recorded by a supervisory system or an operator's confirmation in the MES. When the two ends carry a ninety-second relative offset, every stop duration is wrong by ninety seconds in a consistent direction.

Take an eight-hour shift, so 480 minutes of planned production time, and twelve stops with a true total of 40 minutes of downtime.

True availability      = (480 - 40) / 480      = 440 / 480 = 91.7%

Skew adds 90 s to each of 12 stops:
  phantom downtime     = 12 x 1.5 min          = 18 min
  measured downtime    = 40 + 18               = 58 min
Measured availability  = (480 - 58) / 480      = 422 / 480 = 87.9%

Availability is under-reported by 3.8 percentage points, and since OEE multiplies availability by performance and quality, the headline number moves with it. A plant chasing a four-point availability improvement is now chasing an artefact of a clock. The direction matters too: had the skew run the other way, the same arithmetic would have hidden 18 minutes of genuine downtime per shift, which is the version nobody investigates because the number looks good.

Causality, models and the storage engine

Three further classes of damage are worth naming because they surface at different times.

Root-cause work becomes actively misleading. With a machine running ahead, its events appear earlier than they happened, so an alarm can appear to precede the condition that triggered it. An engineer reading that sequence draws a conclusion that is not merely unsupported but reversed, and the sequence is the primary evidence in most investigations.

Predictive models absorb the offset into their features. A sliding window ending at time t on a skewed device covers a different real interval than the same window on its neighbours, so any feature combining the two is computed over material that does not line up. Where the label comes from a third system — a maintenance record, a quality result — the skew shifts the relationship between features and outcome, and the model either fails to learn a real signal or learns the offset itself.

The storage layer has its own reactions. A timestamp in the future defeats any query bounded by the current time, so a point ninety seconds ahead is invisible to a "last minute" window and then appears later, which reads as flapping. Retention and rollup jobs bucket by timestamp, so a future-dated point can be aggregated into a window that has already been computed, or evicted on a schedule it should not have been subject to. And a clock stepped backwards by a correction produces non-monotonic and possibly duplicate timestamps, which collides with any identity built on device plus timestamp and can silently overwrite a genuine earlier reading.

Finding it requires storing two times

You cannot detect this from the data as usually stored, because a single timestamp column offers nothing to compare against. The mechanism that makes skew observable is recording both the time the event happened, as stamped at the source, and the time your pipeline received it — and then treating the difference as a first-class signal per device rather than as debugging detail.

Charted per device over weeks, that difference has three distinguishable signatures, and knowing which one you have tells you what to fix.

A steadily growing offset is drift: an unsynchronised device with a free-running oscillator, gaining or losing at a roughly constant rate. It will keep growing until someone intervenes, so the size of today's error tells you nothing about next month's.

A flat offset that jumps and then flattens again is a step correction. Something is synchronising the clock occasionally rather than continuously, and each correction creates a discontinuity in the history around it. A sawtooth is this happening on a cycle.

A constant offset that is a whole number of hours, or that appears and disappears on a date in spring or autumn, is not a clock problem at all. It is a timezone or daylight-saving defect: a system storing local time without an offset, so one hour a year is ambiguous and the rest are misinterpreted. This is the most common of the three, and the most often misdiagnosed as skew, because the fix is in a serialisation layer rather than on the device.

Two further checks are worth having. Compare a signal against a physically related one on a different clock — a conveyor's motion and the downstream station's part-present sensor should agree about when a unit arrived, and a consistent lag between them that is not the transport time is your offset. And verify that consecutive timestamps from a device are monotonically increasing, since a violation is proof of a correction rather than an inference about one.

Synchronising the plant does not repair the history

Going forward, the answer is unremarkable: a disciplined time source, NTP across the site with PTP where the process genuinely needs tighter alignment than NTP is designed to give, UTC stored everywhere with the timezone applied only at presentation, and the offset itself monitored so a device falling out of synchronisation is an alert rather than a discovery.

The harder decision is what to do with the year of data already recorded, and this is where the answer separates. Mutating stored timestamps is tempting and is the wrong default for two reasons. It destroys the evidence that the skew existed, so any figure derived before the correction can no longer be reconciled with any figure derived after it, and every past report becomes unreproducible. And where those timestamps form part of a batch record or a released production record, editing them alters a controlled document, which is a change with an approval process attached and not a data-quality task you complete on a Thursday.

The defensible shape is to record the measured offset per device per interval as its own dataset, leave the raw record intact, and apply the correction in the query or view layer where it is visible, versioned and reversible. That also forces the conversation nobody wants to have, which is which previously published numbers were wrong and by how much. Having the arithmetic above ready is what makes that conversation a correction rather than an argument.