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 👍

[pvnguyen123]

Glad i found this post. This was annoying me for awhile, FYI this also affects azure command line due to bad timestamp.

This works for me:

sudo hwclock -s

Below is the error message from az cli in case someone is searching. The error is misleading, but the root cause is that the CLI is using an outdated sys time from WSL2.

You do not have the required permissions needed to perform this operation.
Depending on your operation, you may need to be assigned one of the following roles:
"Storage Blob Data Contributor (Preview)"
"Storage Blob Data Reader (Preview)"
"Storage Queue Data Contributor (Preview)"
"Storage Queue Data Reader (Preview)"

[bertonha]

I had this exactly same problem back on the time that I was using VirtualBox for virtualization, every time my host machine go to sleep. The virtual machine stopped the clock on that time. But when the host come back from sleep, the virtual machine does not look at the time on host machine to update the clock. This simple continue counting the time from where it had stopped.

Exactly the same bug again but now on WSL 2 Virtualization.

[karisN]

I have a slightly different issue. I have powershell and WSL 2 windows up and running side by side. Print the date/time on powershell first then WSL 2, and notice WSL 2 is always slightly behind

PS > Get-Date -Format HH:mm:ss.fffffff
13:58:34.4425582

WSL2 $ date +"%T.%N" 
13:58:34.126019700 

I tried restarting WSL2 in powershell, it'll fix the issue temporary, but will eventually be off again.

Anyone else run into this issue? Is this related to the clock being out of sync with the host?

[benhillis]

This should be much better in build 18970.

[onomatopellan]

@benhillis I thought pausing/unpausing a VM would be the equivalent to sleep a PC but I guess I was wrong. Would it be possible to implement a similar fix when pausing/unpausing a VM?

[Biswa96]

What's the relation between pause/resume of a VM with this issue which is fixed now?

[onomatopellan]

@Biswa96 It's the same problem. If you pause a VM in Hyper-V Manager for some time then after unpausing it system date is not the same and apt update shows this error .

edit:added "Manager" in order to avoid confusion

[onomatopellan]

That's the container. I mean pausing/resuming (2) the virtual machine that runs build 18970 reproduces this issue.

[benhillis]

@onomatopellan - Looks like this fix doesn't work with nested, investigating...

[eriky]

Please all, use the simple and quick fix as mentioned before as long as this issue is not fixed:

sudo hwclock -s

[tommiv]

@danwhitston it's enough to shutdown the VM with wsl --shutdown, no need to reboot. Also chronyd MUST help, as well as sudo hwclock -s. To make chrony more forgiving, take a look at this comment #4245 (comment)

[danwhitston]

Thanks both. You're right, chronyd must have been hitting the skew limit, given WSL's time was out by days rather than milliseconds.

[janfrederik]

Why is this issue closed? It has the label "fixedinreleasebuild", but does not seem fixed in the latest public release or any updates...

[onomatopellan]

@janfrederik This issue was actually fixed. If you still have time sync problems follow #5324 issue instead.

[anthony-steele-cko]

That's funny, I had an incorrect date in WSL on waking my laptop today.
So it does not seem to be "fixed" at all.

[kevinbosman]

sudo hwclock -s does not correct the time for me.

[YoraiLevi]

I have found this issues because this still happens. I was actually writing a topic about the date command and found this behavior by chance, hadn't tried the hwclock -s, but shutting down wsl and restarting it works

[miklevin]

This is not fixed. I reset my clock every day.

[einarpersson]

This is not fixed. I just keep using the sudo hwclock -s. Since correct time is pretty essential, I hope that this (or related) issue is on a high prioritity to fix?

[grtrout]

I can't believe this is still broken. Debating about implementing some kind of hack to mitigate it, but in the meantime I just run sudo hwclock -s occasionally (particularly if I'm about to commit/push code). You would think something like this would be prioritized...surely the WSL maintainers themselves run into this issue all the time.

[Roritharr]

Just ran into this same problem. Why this issue is marked as closed is beyond me.

[garyo]

There's another issue on this topic at #5324, still open since it is not fixed yet.

[airglow923]

To me, it does not seem to occur as of Windows 20H2 update. However, because it is not listed in the resolved issues in Windows 10 version 20H2, I am unsure of why it does not recur after the update.

EDIT: It's still recurring.

[tomqwpl]

I also have this problem. The time reported by Windows appears accurate, seems to match "time.io" for example.
The time reported within WSL2 is about 25 seconds ahead.
The sudo hwclock -s command makes no difference for me, the time within WSL2 is unchanged. Restarting wsl with wsl --shutdown has made the clocks synchronize though.

[ghost]

Is there a solution if hwclock -s doesn't work:

root@6d5befe8cf47:/data# hwclock --verbose
hwclock from util-linux 2.33.1
System Time: 1607018356.723684
Trying to open: /dev/rtc0
Trying to open: /dev/rtc
Trying to open: /dev/misc/rtc
No usable clock interface found.
hwclock: Cannot access the Hardware Clock via any known method.
root@6d5befe8cf47:/data# cat /sys/devices/system/clocksource/clocksource0/available_clocksource
hyperv_clocksource_tsc_page
root@6d5befe8cf47:/data#

[tomqwpl]

Yes, I also get that error. So using hwclock -s on its own produces no output to say its failed, but --versose produces:

hwclock from util-linux 2.34
System Time: 1607018493.397590
Trying to open: /dev/rtc0
No usable clock interface found.
hwclock: Cannot access the Hardware Clock via any known method.

Of course I realise that you need to run it as sudo hwclock -s and that then does work (for me):

hwclock from util-linux 2.34
System Time: 1607018597.374906
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2020/12/03 18:03:18
Hw clock time : 2020/12/03 18:03:18 = 1607018598 seconds since 1969
Time since last adjustment is 1607018598 seconds
Calculated Hardware Clock drift is 0.000000 seconds
2020-12-03 18:03:16.947133+00:00

[ghost]

I was already root. I exec into a redis docker container: docker exec -it redis bash and at that point I'm root but I can't execute hwclock.

[ghost]

Open a bash shell directly from Windows, then try "sudo hwclock -s". That runs but still left me a few seconds behind though.

[Mereep]

Same problem. It is December '20. The bug is from June '19.

This thing is serious since Docker is using WSL 2 now, effectively having wrong clocks in all containers.

[jurij]

prod was broken. solution was do delete windows and install unix system

[davystrong]

Just after spending a whole day trying to work out why a Docker container was getting 403 when connecting to AWS... then checked the date! Very annoying. Why has this issue been closed?

[arcs-]

Bump?

[tomqwpl]

Docker containers having the wrong clock (which is the effect of this issue) is a serious problem. The reason I ran into this was that I have a docker container running a service that is issuing authentication tokens for a web service. Trouble is that you authenticate and get a token, but when you use the token the receiver (not running in docker, and hence having a different clock) complains that the token is being used before it's issued because the clocks aren't in sync. This is just one example, but there would be many ways in which not having the clocks synched will cause unexpected issues.

[pauljfx]

Experiencing the same issue, this did not work for me

sudo hwclock -s

this works for some time but then the time resets again

sudo ntpdate pool.ntp.org

[RoyPour]

If you have a Docker container, don't try changing time within the container. Instead, change the server time with:
sudo ntpdate pool.ntp.org
(if you don't have it on system then install with: sudo apt-get update & sudo apt-get install ntpdate)
or
sudo ~/set-date.sh
given set-date.sh is defined below.

• Having correct time becomes a must when you are pushing or pulling updates to Azure blob or any other data factory.

`# ~/set-date.sh

Get time from a reliable source

TIME_FROM_SERVER=$(curl -v --insecure --silent https://google.com/ 2>&1 | grep Date | sed -e 's/< Date: //');

set stored date and time

date +"%d%m%Y%H%M%S" -d "$TIME_FROM_SERVER";

echo "Time updated with success!";`

[OscBacon]

Hey, I hope this can help :)
I decided to set up a crontab to update my time every 10 minutes.
I think that it's a good way to make sure the time doesn't drift too much.
Note that since you need sudo to run ntpdate, you need to use the sudo crontab:

so, run sudo crontab -e, then add:
10 * * * * ntpdate time.windows.com

[sjschultze]

Folks still commenting on this issue might want to comment on #5324 instead because that one's still open and comments there are probably more likely to get noticed by MSFT than comments on this closed issue.

I can't believe this bug has existed for this long. Wow.