system date is not same with windows (WSL 2)

[erdemece]

• Your Windows build number: 18922

• date is updating itself in WSL 2 even I set the timezone and change date manually with date command

• because the date is wrong I can't sudo apt update and I have to set the date to my local time everytime I open WSL 2

thanks.

[benhillis]

Which distro are you using? Any errors in dmesg? WSL relies on the tzdata package to do the translation.

[erdemece]

Which distro are you using? Any errors in dmesg? WSL relies on the tzdata package to do the translation.

it's ubuntu 18.04
well I just converted from WSL 2 to WSL 1. I will reply after I convert WSL 2 with the outputs.

Thanks.

[radu-matei]

I can also confirm this, and it’s especially bad when changing time zones, leading up to not being able to use a package manager at all.

[joeljwilliams]

[    0.335041] rtc_cmos 00:00: setting system clock to 2019-06-21 22:54:24 UTC (1561157664)
[    0.335057] Unstable clock detected, switching default tracing clock to "global"
               If you want to keep using the local clock, then add:
                 "trace_clock=local"
               on the kernel command line

This is what i see in dmesg related to system time. I'm using the Ubuntu 18.04 WSL 2.

[lmatter]

Me too.

[cxsy]

E: Release file for http://security.ubuntu.com/ubuntu/dists/bionic-security/InRelease is not valid yet (invalid for another 14h 47min 54s). Updates for this repository will not be applied.
E: Release file for http://archive.ubuntu.com/ubuntu/dists/bionic-updates/InRelease is not valid yet (invalid for another 15h 2min 9s). Updates for this repository will not be applied.
E: Release file for http://archive.ubuntu.com/ubuntu/dists/bionic-backports/InRelease is not valid yet (invalid for another 14h 49min 15s). Updates for this repository will not be applied.

This is the error message I got when I run sudo apt update. I think it's related to the wrong system date.
One workaround is switch to WSL1 and then switch back.

[ngasst]

I was having the same issue, but my main gripe was that it was preventing me from reliably working with docker containers in what was otherwise a very workable setup.

Here's my solution along with necessary code snippet.

1. Get time from reliable source on the internet using Curl.
2. Parse time and set it onto the WSL linux instance
3. Create a shell script and modify .rc file to run said script at start

Script:

# ~/set-date.sh

# Get time from google server or some other reliable source
TIME_FROM_SERVER=$(curl -v --insecure --silent https://google.com/ 2>&1 | grep Date | sed -e 's/< Date: //');

# Set stored time
date +"%d%m%Y%H%M%S" -d "$TIME_FROM_SERVER";

echo "Time updated with success!";

After you run this, you should see the current timestamp printed as well as the success message.

Then, in your bashrc, zshrc or equivalent, call the script
sh ~/set-date.sh

CREDIT: I was having trouble with the returned time format. The script above is a barely modified version from here

[MiklerGM]

The problem with the date begins when I put my notebook at sleep, the system clock is ticking but not the WSL one. It can be easily reproduced.

I've been using ntpdate for time sync purposes.

sudo ntpdate pool.ntp.org

[WSLUser]

I would venture using chrony would be a better option than ntp. Or even ntpsec. Just add something similar such as pool 2.fedora.pool.ntp.org iburstto chrony.conf (or ntp.conf). If you have a local NTP server serving up time for all your machines, point there (and please have 2 servers configured. Yes one will work, but it is very bad practice).

However that said, a simple PR to enable "trace_clock=local" in the WSL2 repo should be made.

[peidaqi]

Can confirm. This is a very serious bug, which means any date/time related service would be unreliable in WSL2... including apt.

[Rhahkeem]

Can confirm this as well. On converted distro's and newly downloaded ones. This makes it impossible to download newer packages from apt

[jdub]

Quick fix! In PowerShell or Command Prompt:

wsl --shutdown

Next time you start a WSL session, it'll be a cold boot and the time will be correct.

[benhillis]

We are working on a fix, in the meantime "sudo hwclock -s" should get things working.

[nunix]

just a quick and concrete example of when it happened for me:

• started a WSL2 distro
• made the laptop sleep
• started again the laptop the next day
• checked the date/time -> was still set to the day before

I went the wsl --shutdown route and it worked. Will do the hwclock next time 👍