I switched to Linux last Tuesday, rebooted into Windows an hour later, and the clock read 4:37 PM instead of 7:37 PM. I corrected it manually, jumped back into Linux at lunch, and the clock was three hours ahead again. If you have ever watched the time jump back and forth on a dual-boot machine, that on-again, off-again tug-of-war is exactly what this guide kills for good.
Fixing time drift between Windows and Linux on a dual-boot system comes down to making both operating systems interpret the hardware clock the same way. There are two solid fixes, both of them take under five minutes, and I will walk you through each one plus how to verify the fix actually stuck.
Table of Contents
TL;DR: The 30-Second Fix
If you just want the commands and you trust me, here they are. Pick whichever operating system you are happy editing.
Option A — Linux (Ubuntu, Mint, Fedora, Arch, anything with systemd):
timedatectl set-local-rtc 1 --adjust-system-clockOption B — Windows (registry edit):
reg add "HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTimeZoneInformation" /v RealTimeIsUniversal /t REG_DWORD /d 1 /fThat is it. Reboot into the other OS, check the clock, and the time should match within one second. If you want to understand what those commands actually do, keep reading.
Why Does Time Drift Between Windows and Linux?
The drift happens because Linux and Windows disagree on what the hardware clock means. Linux assumes the battery-backed clock on your motherboard stores UTC (Coordinated Universal Time). Windows assumes it stores local time. So one of them is always wrong, and which one looks wrong depends on which OS you booted most recently.
Quick example. Say your real local time is 2:00 PM in New York, and your UTC offset is minus four hours. The hardware clock physically reads 18:00. Linux reads 18:00 and treats it as UTC, so it displays 2:00 PM. Windows reads the same 18:00 and treats it as local, so it displays 6:00 PM. Same number on the chip, completely different result on screen.
The reason this looks asymmetric is simple: Linux writes UTC back to the RTC. Windows writes local time back to the RTC. Every time you boot into Windows, it overwrites your UTC-true clock with a local-time value. Every time you boot back into Linux, it sees that local-time value and decides you are living in a wildly different timezone.
Understanding the Hardware Clock (RTC)
Your computer has two clocks. The first is the system clock, a software counter that runs while the OS is up. The second is the real-time clock (RTC), a tiny battery-backed chip on the motherboard, often called the CMOS clock or BIOS clock, that keeps ticking even when the laptop is unplugged in your bag for two weeks.
The RTC is what each operating system reads at boot to set its initial system clock. From there, the OS usually pulls a fresh time from an NTP (Network Time Protocol) server and corrects any drift. The catch is that Windows also re-syncs the RTC with local time. Linux re-syncs it with UTC. Neither one waits to ask the other what convention to use.
UEFI-based motherboards store the RTC value in a small persistent memory area. Older BIOS boards stored it in CMOS RAM. The principle is identical; only the storage location changed.
Which Fix Should You Pick?
Either fix works. Most people pick whichever operating system they edit less often. If you live in Linux and only dip into Windows for the occasional game, change Linux. If Windows is your daily driver and Linux is for emergencies, change Windows.
Modern Linux distributions (Ubuntu 16.04+, Fedora 24+, anything using systemd 232 or later) include a safety check that warns you when the RTC is set to local time. You will see a yellow notice every boot. It is annoying but harmless. The warning exists because Microsoft, Apple, and the Linux kernel team all agree UTC is the cleaner standard, and they would prefer you do not deviate from it.
Method 1: Make Linux Use Local Time (timedatectl)
The timedatectl command is part of systemd and ships with every mainstream Linux distribution built in the last decade. Open a terminal and run:
timedatectl set-local-rtc 1 --adjust-system-clockThe --adjust-system-clock flag tells Linux to convert the stored UTC value to local time right now, so you do not see a jump on this boot. Without it, the system clock would stay at UTC until NTP corrected it, and your desktop clock widget would show the wrong time for a few seconds.
Check the result with:
timedatectlYou should see a line that says RTC in local TZ: yes. If it says no, the command silently failed, usually because of missing permissions. Re-run with sudo timedatectl set-local-rtc 1 --adjust-system-clock.
To undo this later and return to UTC on the hardware clock, run:
timedatectl set-local-rtc 0 --adjust-system-clockMethod 2: Make Windows Use UTC Time (Registry Edit)
Windows keeps its setting in a single registry value called RealTimeIsUniversal. By default it does not exist, and Windows treats the RTC as local. We need to create the value and set it to 1.
Open an elevated Command Prompt (right-click the Start menu, choose Windows Terminal (Admin) or Command Prompt (Admin)). Then run:
reg add "HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTimeZoneInformation" /v RealTimeIsUniversal /t REG_DWORD /d 1 /fThat single line creates the key, sets it to type REG_DWORD, gives it the value 1, and the /f flag forces an overwrite if it already exists.
If you prefer the Registry Editor GUI, hit Win+R, type regedit, and navigate to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTimeZoneInformation. Right-click in the right pane, choose New, then DWORD (32-bit) Value, name it RealTimeIsUniversal, and set its data to 1.
If you would rather download a pre-made file, several guides (including the original How-To Geek article from 2026) host a small .reg file that applies the change with one click. Merge it, reboot, done.
To reverse this, either delete the RealTimeIsUniversal value or run:
reg delete "HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTimeZoneInformation" /v RealTimeIsUniversal /fHow to Verify the Fix Worked
Do not trust the visible clock widget on either desktop. Both operating systems will silently sync from NTP within minutes and overwrite your RTC, so the displayed clock will look right even when the RTC is still wrong.
On Linux, run timedatectl and look for RTC in local TZ: yes (Method 1) or System clock synchronized: yes plus a recent NTP sync (Method 2). You can also check the raw RTC value with sudo hwclock --show. Compare that against UTC and the math should line up.
On Windows, open Command Prompt and run w32tm /query /status. The Source: line should show a successful NTP source like time.windows.com. For a deeper check, run reg query "HKLMSYSTEMCurrentControlSetControlTimeZoneInformation" /v RealTimeIsUniversal. You should see 0x1.
The most reliable test is to disable the network, reboot twice (once into each OS), and confirm the clock is still right. Turn the network back on after the second reboot.
Why This Matters for Developers
If you write code on Linux and commit from Windows (or vice versa), Git uses the system clock to stamp every commit. A wrong clock means commits that look like they came from the future or the deep past, which breaks git log --since, confuses teammates in different timezones, and can trip CI pipelines that refuse to build artifacts dated in the future.
Build systems that bake timestamps into binaries (Go, Rust, C++) will embed a wildly wrong build time. Container images with skewed timestamps fail reproducibility tests. Cron jobs and systemd timers that trigger off the system clock will fire at the wrong wall-clock minute. If you have ever seen a backup run twice or not at all, look at the clock first.
Log correlation across both operating systems also depends on a sane clock. If you SSH from a Windows machine into a Linux server and the timestamps in your terminal do not line up with the server logs, troubleshooting gets much harder.
What About Windows Server and macOS?
The same RealTimeIsUniversal registry trick works on Windows Server 2016, 2019, and 2022. If you run a server that dual-boots into a Linux recovery environment, you can use the registry to keep clock interpretation consistent.
macOS already treats the hardware clock as UTC by default, so Mac users dual-booting Linux do not see this problem. If you Boot Camp a Mac and run Windows alongside, you do need to set Windows to UTC the same way.
Daylight Saving Time and Edge Cases
Daylight saving time will not break either fix. Both operating systems adjust their display for DST automatically. The only thing to know is that you should not run your NTP sync right at the DST rollover minute, because some implementations briefly show stale offsets.
Some Linux distributions still ship without timedatectl (very old distros, custom embedded builds). On those, you can edit /etc/adjtime and change the third line from UTC to LOCAL. Reboot and you are set.
Frequently Asked Questions
How do I fix time drift between Linux and Windows on a dual-boot system?
Run timedatectl set-local-rtc 1 u002du002dadjust-system-clock on Linux, or add the RealTimeIsUniversal DWORD value of 1 under HKEY_LOCAL_MACHINEu005cSYSTEMu005cCurrentControlSetu005cControlu005cTimeZoneInformation on Windows. Pick one method, reboot into the other OS, and the clock will match.
Why does my Windows clock show wrong time after booting Linux?
Linux writes UTC to the hardware clock, but Windows reads the hardware clock as local time. The difference between UTC and your local timezone is exactly the offset you see when you boot Windows after using Linux.
Which is better: UTC or local time for the hardware clock?
UTC is the cleaner standard and is what Apple, Microsoft, and the Linux kernel team all recommend. However, when running a dual-boot setup with Windows, both OSes must agree, so the simpler fix is often to set Linux to local time rather than touch the Windows registry.
Is it safe to dual boot Windows and Linux?
Yes. Modern GRUB and Windows Boot Manager coexist well as long as you install them in the correct order. The most common annoyance is exactly the time drift issue this guide fixes, followed by BitLocker prompts on Windows after a Linux install.
Will timedatectl set-local-rtc survive Windows updates?
Yes. The setting lives in systemd-managed configuration and is independent of the Windows registry. Windows cannot reach into the Linux side and reset it. The reverse is also true: Windows updates will not delete the RealTimeIsUniversal value on their own.
Do I still need NTP if I fix the RTC?
Yes. The RTC keeps time when the machine is off, but hardware clocks drift by a few seconds per week. NTP keeps the system clock accurate to within milliseconds and only writes back to the RTC at shutdown. Both layers work together.
Wrapping Up
That is the whole fix. Pick the operating system you are more comfortable editing, run the one command, reboot into the other OS, and the clock will match from then on. The drift was never a bug; it was just two operating systems reading the same hardware clock with different rules.
If you maintain a fleet of dual-boot machines, roll the chosen fix into your provisioning script. For Linux, that means a single timedatectl line in your Ansible, Puppet, or cloud-init config. For Windows, push the registry value via Group Policy or PowerShell. Once it is automated, you never think about the clock again.