Fix Time Jumps Between Linux and Windows (Dual-Boot)

Synchronizing Time Between Linux and Windows in Dual-Boot Setups

If you run both Linux and Windows on the same machine, you might notice that after rebooting, your system clock jumps by a few hours.

This happens because both systems read the same hardware clock but interpret it differently: Windows treats it as local time, while Linux treats it as UTC.

To fix this, both systems need to use the same time reference. There are two main approaches:

Use UTC for both systems (recommended):

• On Linux:

timedatectl set-local-rtc 0 --adjust-system-clock

It's not necessary because Linux uses UTC by default, but this explicitly ensures the setting.

• On Windows: Use this command:

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /t reg_dword /d 1 /f

It will add a registry key to treat the hardware clock as UTC.
You can save it in a .txt file, rename it to switch-to-utc-time.bat and run as administrator. Alternatively, open a cmd or PowerShell window as administrator, paste the line, and press Enter.
Ater applying the registry setting, restart Windows.

Use local time for both systems (Windows default):

• On Linux:

timedatectl set-local-rtc 1 --adjust-system-clock

Then reboot.

After this change, both OS clocks will stay in sync, preventing issues with logs, Git commits, scheduled tasks, or databases caused by time jumps.

---

What is hardware clock and where is it stored?

The hardware clock, sometimes called RTC or CMOS clock, is built into the motherboard and keeps time even when the computer is powered off.

You’ve probably remembered that small CMOS battery — the one that used to make your clock reset when it died, and maybe the one you’ve even replaced yourself.

Both Linux and Windows read this clock at startup.

See also:
https://en.wikipedia.org/wiki/Real-time_clock

Why time jumps feel asymmetric in dual-boot setups

You may notice that switching from one OS to another breaks the clock, but switching back does not always fix it. This asymmetry happens because each OS not only reads the hardware clock differently, but also writes to it on shutdown.

If one system writes UTC and the other later reads it as local time (or vice versa), the offset gets applied twice. Each reboot reinforces the mismatch until both systems agree on how the hardware clock should be interpreted.

The only real fix is consistency: both systems must treat the hardware clock the same way — ideally as UTC.

Why Windows uses local time by default

This behavior is mostly historical. Early PCs, MS-DOS, and early Windows versions assumed single-user, single-location machines. Storing local time in the hardware clock made the system immediately show the “correct” time for the user after boot.

Modern Windows inherited this design for backward compatibility. Linux, on the other hand, adopted UTC as a system default much earlier, especially for servers and networked environments.

UTC vs local time: standard vs convenient simplification

UTC is an international time standard based on atomic clocks. In practice, it acts as the “base unit” for time in computing: it does not change with daylight saving time and does not depend on geography.

Local time, as used by Windows by default, is not a different standard — it is simply UTC plus a timezone offset and daylight saving rules applied for user convenience. This makes it suitable for display, but fragile as a system-level reference.

What about Windows Server? How does it stay synchronized?

Windows Server behaves the same way as desktop Windows: by default, it treats the hardware clock as local time, not UTC. This can add friction in real-world environments, because most servers on the internet — Linux hosts, containers, cloud VMs, CI/CD systems — operate in UTC.

When Windows Server uses local time while the rest of the infrastructure uses UTC, administrators may face:

• Misaligned timestamps across systems
• Confusing log correlation during incident analysis
• Scheduled jobs running at unexpected times
• Extra mental overhead when debugging time-related issues

For this reason, Windows Server is often explicitly configured to use UTC by setting the same RealTimeIsUniversal registry key and syncing time via NTP.

Why this matters for users

If your clocks aren’t in sync, you might notice:

• Files showing the wrong creation or modification time.
• Scheduled tasks running too early or too late.
• Confusing timestamps in logs.

Why this matters for developers

For developers, having consistent system time is critical. When dual-boot clocks drift, you may encounter:

• Git commits appearing with the wrong timestamp.
• Build systems triggering unnecessary rebuilds due to “past” or “future” timestamps.
• Scheduled tasks running at unexpected times.
• Logs from different OSes or containers being misaligned.

Using UTC is generally better because it avoids timezone-related issues and daylight saving changes. Linux servers, Docker containers, CI/CD pipelines, and cloud environments almost always operate in UTC, so aligning your local machine avoids subtle bugs in development workflows.