If the system time on a Windows virtual machine shifts by several hours after a shutdown or restart, the cause is usually a mismatch in how Windows and the virtualisation host interpret the hardware clock.
Windows expects the hardware clock (RTC) to hold local time. Linux-based hosts, including Proxmox, normally keep it in UTC. When the two disagree, Windows applies the time-zone offset to a value that already includes it, and the clock ends up wrong by exactly the offset of your time zone.
Check these first
Before editing the registry, confirm the simpler possibilities:
- the correct time zone is selected in Windows;
- Windows time synchronisation is enabled and working — if the clock corrects itself after a few minutes, the problem is only at startup;
- if the shift is not a whole number of hours, this article does not apply: that points to a synchronisation problem rather than an RTC mismatch.
If the offset matches your time zone exactly and appears after every power cycle, continue.
Tell Windows the hardware clock is UTC
Incorrect registry changes can leave the operating system unusable. Take a snapshot before you start — see Backups and snapshots for CloudVM virtual servers — and change only the value named below.
- Sign in with an administrator account.
- Press
Win + R, typeregeditand click OK. - Go to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
- Right-click in the right-hand pane and choose New → DWORD (32-bit) Value.
- Name it
RealTimeIsUniversal. - Open it and set the value data to
1. - Click OK and close the Registry Editor.
Or apply it with a .reg file
Create a file with the .reg extension containing:
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation] "RealTimeIsUniversal"=dword:00000001
Run it as administrator and confirm the prompt.
Power the machine off and on
A full power cycle is required — Restart is not enough, because the hardware clock is only re-read at power-on. Shut the server down and start it again from the client area: see Managing your CloudVM virtual server in the client area.
After it comes up, check the clock. It should now be correct and stay correct across further restarts.
If the time is still wrong
Open a ticket from your client area stating the size of the shift, whether it appears after a restart or a full power-off, and which Windows version the server runs. The virtual machine's own clock settings are configured on our side, and we can check them against what Windows expects.
Why this matters beyond convenience
A wrong clock causes problems that do not look like clock problems: TLS certificate validation failures, mail rejected by receiving servers, scheduled tasks running at the wrong time, and log entries that cannot be correlated with anything. Worth fixing properly rather than correcting the time by hand each time.