The best practice is to use UTC as the system time of record for events, keep the plant or asset local timezone as metadata, and apply timezone conversion only at the reporting layer under controlled rules.
That is usually the least risky approach for KPI reporting because daylight saving time creates two known problems in local time:
In the spring, one local hour does not exist.
In the fall, one local hour occurs twice.
If your KPIs are calculated directly from local timestamps without explicit handling for those cases, hourly trends, shift totals, downtime buckets, utilization, OEE, and SLA-style metrics can be wrong. The error may be small for some dashboards and material for others.
Store raw event time in UTC. This should apply to machine events, transactions, alarms, operator actions, historian records, and integration messages where possible.
Store timezone context separately. Keep the site timezone, and if relevant, the production line or asset timezone. Do not assume all plants operate in the same zone.
Define reporting rules for local-period KPIs. If management wants reporting by local shift, local day, or local hour, document exactly how DST transition periods are handled.
Use timezone-aware libraries and databases. Hard-coded DST offsets and manual calendar logic tend to fail over time.
Test both DST transition dates. Validate spring-forward and fall-back behavior in calculations, dashboards, exports, and interfaces.
Version-control the KPI definition. If a report changes from local-time aggregation to UTC-first aggregation, treat that as a governed metric change, not a cosmetic edit.
There is no single universal answer because the right method depends on how the KPI is used.
For cross-site comparison: UTC-based aggregation is usually more consistent.
For plant operations review: local-time presentation is often necessary, but the aggregation logic still needs to account for missing or repeated hours.
For shift-based accountability: tie the KPI to the scheduled shift definition, not just a clock hour. A shift on a DST transition day may be shorter or longer than nominal.
For example, a night shift during the fall transition may contain 9 clock hours in local time, while the spring transition may contain 7. If your reporting system forces every shift to 8 hours without exception, some metrics will be distorted. Whether that is acceptable depends on the business rule, but it should be intentional and documented.
Do not let each dashboard author handle DST differently.
Do not rely on spreadsheet adjustments as the main control.
Do not overwrite original timestamps after conversion.
Do not assume ERP, MES, SCADA, historians, and BI tools all interpret timezone data the same way.
Do not hide the issue by summarizing only daily values if hourly and shift-level decisions matter.
In many plants, you will not be able to standardize this instantly. Older MES, historians, PLC-connected systems, custom integrations, and ERP extracts may already store local time differently, or with incomplete timezone metadata. Some systems can be changed easily; others cannot without validation effort, downtime risk, or downstream reporting impact.
In that environment, the practical approach is usually coexistence:
leave source systems unchanged if changing them would create unnecessary operational risk,
normalize timestamps in the integration or data platform layer,
add a governed semantic rule for KPI aggregation, and
document system-by-system exceptions.
A full replacement just to solve DST handling is rarely justified in regulated, long-lifecycle operations. The qualification burden, integration complexity, downtime risk, and report revalidation effort are often larger than the timing issue itself.
The best way is not to “manage DST” manually in KPI reports. It is to design time handling so DST becomes a controlled reporting rule rather than a recurring data-quality defect: UTC for system record, local timezone retained as context, explicit aggregation rules for local operational KPIs, and validation of edge cases before the numbers are trusted.
Whether you're managing 1 site or 100, Connect 981 adapts to your environment and scales with your needs—without the complexity of traditional systems.
Whether you're managing 1 site or 100, C-981 adapts to your environment and scales with your needs—without the complexity of traditional systems.
