Glossary

Daylight savings time (DST)

A seasonal clock change that shifts local civil time, affecting timestamps, schedules, and system synchronization.

Data Integration, Security and Trust Data Integrity, Version Control and Audit Trails MES, ERP, PLM and Data Integration

Daylight savings time (DST) commonly refers to the seasonal practice of moving local civil clocks forward for part of the year and back again later. It changes the displayed local time, but it does not change the underlying passage of time itself.

In industrial operations, DST matters because many systems record, display, exchange, or trigger events based on time. MES, ERP, SCADA, historians, batch records, alarms, reports, and audit trails can all be affected when local clocks skip forward or repeat an hour.

How it shows up in operations and systems

DST most often appears as a time-handling issue in software, devices, and records rather than as a manufacturing process setting. Common examples include:

Timestamps that appear to jump forward or repeat during the changeover window
Shift schedules, labor records, or production reports that need correct hour attribution
Interfaces between systems that use different time zones or different DST rules
Alarm, event, and audit logs that must preserve event order across the clock change
Planned jobs, backups, or integrations scheduled by local time

For this reason, organizations commonly distinguish between local display time and a standard reference time such as UTC when storing or reconciling records.

What it includes and excludes

DST includes the seasonal offset applied by a jurisdiction’s local time rules. It does not mean a time zone by itself, and it does not refer to general clock synchronization methods such as NTP. It also does not guarantee that every country, region, plant, or software platform follows the same start and end dates.

Common confusion

DST is often confused with time zones. A time zone is the regional rule set for local civil time, while DST is an optional seasonal adjustment within some time zones. It is also commonly confused with UTC. UTC is a fixed reference time and does not observe DST.

Another common confusion is the phrase itself. In common usage, people say both “daylight saving time” and “daylight savings time.” The formal term in many technical references is “daylight saving time,” but DST is widely understood either way.

You do not validate a process drift model by showing good accuracy on historical data alone. In a customer-regulated aerospace program, validation usually requires a documented intended use, verified data lineage, measurement-system adequacy, change control, and evidence that model outputs are bounded, reviewable, and compatible with existing quality and production controls.

Can I build AI models directly on my MES database without a data warehouse?

Yes, in some cases, but it is usually a poor default for regulated manufacturing. Directly training on an MES database can create performance, data quality, traceability, and validation problems. It may work for small read-only use cases, but production AI typically needs a governed data layer, whether that is a warehouse, lakehouse, or curated replica.

What is the relationship between configuration control and engineering change management?

Configuration control and engineering change management are tightly linked but not identical. Configuration control defines and governs the approved product and process baselines over time, while engineering change management is the formal workflow for proposing, assessing, approving, and implementing changes that alter those controlled configurations. In regulated, long-lifecycle manufacturing, both must integrate with PLM, ERP, MES, and QMS, and be supported by traceable, validated workflows rather than ad hoc changes, to avoid gaps between design intent, released documentation, and actual as-built/as-maintained records.

How do we ensure MES data is trusted for KPI reporting?

You cannot “declare” MES data trustworthy for KPI reporting; you have to design, prove, and continuously maintain that trust. This requires clear KPI definitions, data lineage and traceability, controlled integrations, validation of calculations, tight change control, and ongoing reconciliation against physical reality and other systems.

Related Glossary