The Issue
The BIOS clock on a Windows machine affects how the operating system interprets time — and this can have downstream effects on PLC communication timestamps, historian data, and software licensing.
How It Works
Windows assumes the BIOS time is set to local time (in your configured timezone). If the BIOS is set to UTC but Windows thinks it is local time, the OS will apply the timezone offset on top of what it thinks is already local — resulting in a time that is off by several hours.
The Chain of Problems
- NTP synchronization — if the initial BIOS time is far off, NTP may take a long time to correct it or may refuse to sync (depending on the NTP client configuration and the maximum allowed offset).
- Software licensing — many industrial software packages (Aveva, Rockwell, Schneider) use time-based license validation. If the system clock is wrong, license checks may fail, causing the software to enter demo mode or refuse to start.
- PLC timestamps — if the PLC syncs its clock from the SCADA server or engineering workstation, a wrong system time propagates to the controller. Alarm timestamps, event logs, and sequence-of-events records all become unreliable.
- Historian data — data logged with incorrect timestamps is difficult to correlate with field events. Regulatory reporting can be affected.
Configuration Checklist
- Set the BIOS clock to the correct local time (or UTC if the OS is configured to expect UTC — Linux typically expects UTC, Windows expects local).
- Configure the Windows timezone correctly for the site location.
- Set up NTP synchronization to a reliable time source (site NTP server, or GPS-based time source for critical facilities).
- Verify the time on the PLC, SCADA server, and historian all agree within acceptable tolerance (typically ±1 second).
- Document the NTP configuration and timezone settings in the site as-built documentation.