5

Running Ubuntu in WSL2 my clock is getting screwed up somehow. And when I try to set it again using:

sudo dpkg-reconfigure tzdata

It still gets set about an hour behind the real time.

The screenshot shows the real current time in Windows, and also Windows via an RDP connection to the machine running WSL2/Ubuntu.

The purple terminal window is the Ubuntu having trouble.

Not super-great with Linux; any idea what's causing the time to be set wrong?

enter image description here

J. Scott Elblein
  • 212
  • I know that Windows sets the hardware clock to local time instead of UTC because it's a barbaric neanderthal. In dual boot configurations you have to either change how Windows or Ubuntu derives local time, but I was not aware that this is necessary in WSL. Did you or some application explicitly set the time or adjust time settings in Ubuntu? Because it's possible that messing with it caused the same discrepancy in a dual boot config. You may need to make Ubuntu derive time from local time, or you can configure Windows to derive local time from UTC. https://askubuntu.com/q/169376 – Nmath Jan 11 '22 at 21:19

1 Answers1

11

Is there any chance the computer has been in Sleep or Hibernate, or is the WSL machine running in a VM? That was (at one point) known to cause WSL's "hardware clock" to become out-of-sync with the real/Windows time.

Reference: This Stack Overflow answer and the related Github issue.

The core issue (at least the Sleep/Hibernate issue) is fixed by the 5.10.16.3 WSL2 kernel release, which you can update to (if you aren't on it already) with wsl --update (in recent Windows releases) or via Windows Update (assuming you have allowed "other Microsoft products" to update as part of it).

However, there may still be clock drift issues, as noted in that Github issue.

If so, try a sudo hwclock -s, and if that doesn't fix it, a wsl --shutdown and restart.

NotTheDr01ds
  • 17,888
  • 1
    Sounds like you've hit the nail on the head. I came across this later, which also mentions hibernation being an issue (https://tomssl.com/fixing-clock-drift-in-wsl2-using-windows-terminal). Recently the power went out in a storm, and send that WSL computer into hibernation. I think that probably did it. Currently I used the workaround on his page, but will look into using one from the above as well. thanks! – J. Scott Elblein Jan 11 '22 at 23:07
  • 1
    As a side note I just checked the WSL kernel version and it's Kernel version: 5.10.60.1. Looks like they didn't get it sorted out yet, lol. – J. Scott Elblein Jan 11 '22 at 23:18
  • x86_64 Linux 5.15.90.1-microsoft-standard-WSL2 and is still broken – Axeltherabbit Mar 08 '23 at 14:22
  • Using wsl --update is a great hotfix for WSL issues. Fixes time-drift and update errors in signed repos. Highly recommend! Note, if you leave a WSL process—like a VS Code instance—open when the computer sleeps/hibernates that can cause some issues. – jon.bray.eth Apr 14 '23 at 11:47
  • @SentientFlesh wsl --update checks for a new release of WSL. If it finds it, it shuts down (e.g. wsl --shutdown, as mentioned in my answer) and installs it. However, if there's no new WSL update, then wsl --update is a no-op as far as I can tell. I just tested this by setting the date incorrectly in Ubuntu, then running a wsl --update, which did not correct the date/time. Can you provide more info on what behavior you are seeing with wsl --update? Thanks! – NotTheDr01ds Apr 14 '23 at 12:13
  • @NotTheDr01ds With incorrect time, ran wsl --update in PS and it fixed the time. Ran the command with correct time and got: 
    Checking for updates.
The most recent version of Windows Subsystem for Linux is already installed.

    Changed WSL time using sudo date -s "2027-11-11 11:11:11" and confirmed with date.

    Ran wsl --update in PS again, received the same message as above, but now my WSL time is correct from when before I changed it manually.

     – jon.bray.eth May 02 '23 at 00:36
  • @NotTheDr01ds Ah, I just found out why wsl --update seemed to be working. Since I have one remote server I connect to over a VPN that requires the server time to match I have a check in my .bashrc that checks to make sure I'm not connected to said server, and if not, run sudo hwclock -s to correct the system time if needed. So that little line in my .bashrc was making it look like wsl --update was working when really it was just WSL performing a check on whether or not it's okay to update the time. – jon.bray.eth May 02 '23 at 00:41