Fix Dual-Boot Clock Mismatch Between Windows and Ubuntu
Iwan Efendi2 min
Fix the clock jumping hours when switching between Windows and Ubuntu by making both OS read hardware RTC as UTC.
If you dual-boot Windows and Ubuntu, you've almost certainly seen this: the clock in Windows suddenly jumps several hours forward or backward right after booting from Ubuntu. It's not a bug — it's a fundamental disagreement between the two operating systems about how to read time from your motherboard.
I spent an embarrassing amount of time thinking my BIOS battery was dying before I realized the actual cause.
The problem comes down to how each OS interprets the RTC (Real-Time Clock) — the hardware clock on your motherboard.
Open PowerShell as Administrator (Win + X → Terminal (Admin)):
You should see If
Boot into Ubuntu and enable NTP sync:
Verify with:
The output you're looking for:
The critical line is
You can set up either OS first. The fixes are independent of each other. What matters is that both are configured — if you only fix one side, the clock drift will come back every time you switch.
You can also solve this from the opposite direction — telling Linux to store local time in the hardware clock:
It works, but I do not recommend it. UTC in the RTC is the Linux standard: logs, file timestamps, containers, and remote servers all assume it, and
Does
After both sides are set, the clock stays consistent no matter how often you switch between operating systems. No more manual time corrections. If you're setting up a dual-boot with a fresh Windows install, it's worth doing this right from the start — it's a two-minute fix that saves a lot of minor annoyance. And while you are polishing the dual-boot experience, the next two annoyances worth killing are the GRUB menu and the Plymouth blank screen — I wrote those steps up in my GRUB and Plymouth guide.
The Root Cause
- Windows reads RTC as local time (e.g. UTC+7 for WIB)
- Ubuntu/Linux reads RTC as UTC, then converts to local time in software
Fix: Windows Side (Registry)
1
Add the RealTimeIsUniversal registry key
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /t REG_DWORD /d 1 /f2
Verify the registry entry
reg query "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal0x1 in the output. That confirms Windows will now treat the hardware clock as UTC.3
Force NTP time sync
net start "Windows Time"
w32tm /config /manualpeerlist:"time.windows.com" /syncfromflags:manual /reliable:YES /update
w32tm /resync /forcew32tm /resync fails with "no time data was available", make sure the /config command ran first — the order matters.4
Restart Windows
A reboot is required for the registry change to take full effect.Fix: Ubuntu Side (NTP)
sudo timedatectl set-ntp truetimedatectl statusSystem clock synchronized: yes
NTP service: active
RTC in local TZ: no
RTC in local TZ: no — that confirms Ubuntu is reading the hardware clock as UTC, which is the correct default.
Order Doesn't Matter
Quick Reference
| OS | Action |
|---|---|
| Windows | Add RealTimeIsUniversal=1 registry key + NTP sync |
| Ubuntu | Enable NTP + confirm RTC in local TZ: no |
Alternative: Make Linux Read the RTC as Local Time
timedatectl set-local-rtc 1 --adjust-system-clocktimedatectl itself warns about this mode. The Windows-side registry fix keeps both systems on the standard path.
Common Pitfalls
- Fixing only one OS. Skip the registry key on Windows or NTP on Ubuntu and the drift comes back on the next switch.
w32tm /resyncfailing with "no time data was available". Run the/configcommand first — the resync depends on it.- BitLocker recovery prompts. On some machines a large clock jump makes Windows ask for your BitLocker recovery key. On a work laptop with BitLocker enabled, fix the clock mismatch before it bites you.
- A dying CMOS battery is not this. If the clock resets to a 2000-something date on every boot regardless of which OS you used, the motherboard battery needs replacing — no registry key will help.
FAQ
RealTimeIsUniversal break Windows updates or my timezone?
No. Windows still displays your local time — it just reads the hardware clock as UTC, the same way Linux does.
Is the registry change safe on a Windows-only machine?
It is a documented Microsoft value and harmless, but on a single-boot machine it changes nothing useful, so leave it alone there.
Can I apply the same fix on Fedora, Arch, or other distros?
Yes. The Linux side is just timedatectl set-ntp true; only the package manager commands differ.
After both sides are set, the clock stays consistent no matter how often you switch between operating systems. No more manual time corrections. If you're setting up a dual-boot with a fresh Windows install, it's worth doing this right from the start — it's a two-minute fix that saves a lot of minor annoyance. And while you are polishing the dual-boot experience, the next two annoyances worth killing are the GRUB menu and the Plymouth blank screen — I wrote those steps up in my GRUB and Plymouth guide.
References
Topics
Topics in this note
Explore related ideas through the topics connected to this note.
Share this article
Discussion
Preparing the comments area...