In most cases, yes: store the authoritative system timestamp in UTC, and also preserve the local context needed to interpret what happened on the shop floor.
For manufacturing records, UTC is usually the safest base for sequencing events across systems, plants, and time zones. It avoids ambiguity during daylight saving transitions, supports cross-site analytics, and makes integrations between MES, ERP, QMS, historians, and data platforms easier to reconcile.
That said, UTC alone is often not enough for operational use. People investigating a deviation, reviewing an electronic record, or reconstructing a batch or unit history may need to see the event in local plant time. If you only keep UTC and discard the original context, you can create confusion during review and troubleshooting.
Practical approach
-
Store the canonical event timestamp in UTC.
-
Also store the plant or site time zone identifier.
-
Preserve the UTC offset in effect at the time of the event, especially where daylight saving changes apply.
-
Display local time to users where that supports operations, review, and investigation.
-
Be explicit in interfaces, reports, and exports about whether a timestamp is UTC or local.
This dual approach is usually more robust than choosing only one or the other.
Why local-only storage is risky
Storing only local time is usually a bad idea in multi-system environments. The main failure modes are predictable:
-
Ambiguity during daylight saving fall-back, when the same local clock time occurs twice.
-
Inconsistent ordering of events across plants or systems configured in different time zones.
-
Complex reconciliation when ERP, MES, SCADA, LIMS, QMS, and reporting tools do not share the same clock assumptions.
-
Higher effort during investigations, data migration, and enterprise analytics.
In regulated and traceability-heavy operations, those ambiguities can matter. They do not automatically create a compliance issue, but they can complicate evidence review, exception analysis, and record reconstruction.
When the answer depends
If a system is strictly local, never integrated, and used only within one site, local time may be workable. But that is less common than teams assume. Over time, most plants need data to flow into other systems, corporate reporting, or long-term archives. What seems simple locally can become expensive later.
The answer also depends on your application architecture. Some legacy systems store local server time by design, some historians have their own conventions, and some vendor products display local time while storing UTC underneath. You need to confirm actual behavior, not assume it.
Brownfield reality
You do not need to replace every legacy system to standardize timestamp handling. In fact, full replacement often fails in long-lifecycle regulated environments because of qualification burden, validation cost, downtime risk, integration complexity, and the difficulty of preserving traceability across established processes.
A more realistic path is to define a timestamp standard at the integration and data-model level:
-
Document which source systems emit UTC, local time, or ambiguous timestamps.
-
Normalize timestamps in middleware, data pipelines, or canonical models where practical.
-
Retain source values for traceability when records are regulated or quality-relevant.
-
Validate transformations, especially for daylight saving boundaries, late-arriving events, and historical migrations.
This is not just a formatting issue. It affects event sequencing, genealogy, downtime analysis, exception review, and cross-system trust in the data.
Implementation cautions
-
Do not rely on manual user entry of time zones.
-
Do not assume server local time equals plant local time.
-
Do not overwrite original timestamps during migration without preserving lineage.
-
Test daylight saving transitions explicitly.
-
Put timestamp conventions under change control so reports, interfaces, and audit trails stay consistent.
So the short answer is: use UTC as the canonical stored time, but keep enough local context to make the record understandable and defensible in operations.