Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

system date is not same with windows (WSL 2) #4245

Closed
erdemece opened this issue Jun 29, 2019 · 135 comments
Closed

system date is not same with windows (WSL 2) #4245

erdemece opened this issue Jun 29, 2019 · 135 comments
Assignees
Labels
wsl2

Comments

@erdemece
Copy link

@erdemece erdemece commented Jun 29, 2019

  • 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.

@erdemece erdemece changed the title system date is not same with windows system date is not same with windows (WSL 2) Jun 29, 2019
@benhillis
Copy link
Member

@benhillis benhillis commented Jun 29, 2019

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

@erdemece
Copy link
Author

@erdemece erdemece commented Jun 29, 2019

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
Copy link

@radu-matei radu-matei commented Jun 30, 2019

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.

@BlaQPhoeniX
Copy link

@BlaQPhoeniX BlaQPhoeniX commented Jun 30, 2019

[    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
Copy link

@lmatter lmatter commented Jul 2, 2019

Me too.

@cxsy
Copy link

@cxsy cxsy commented Jul 2, 2019

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
Copy link

@ngasst ngasst commented Jul 2, 2019

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
Copy link

@MiklerGM MiklerGM commented Jul 3, 2019

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
Copy link

@WSLUser WSLUser commented Jul 3, 2019

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
Copy link

@peidaqi peidaqi commented Jul 7, 2019

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

@Rhahkeem
Copy link

@Rhahkeem Rhahkeem commented Jul 7, 2019

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

@jdub
Copy link

@jdub jdub commented Jul 9, 2019

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
Copy link
Member

@benhillis benhillis commented Jul 10, 2019

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

@nunix
Copy link

@nunix nunix commented Jul 23, 2019

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 👍

@benhillis benhillis self-assigned this Jul 23, 2019
@pvnguyen123
Copy link

@pvnguyen123 pvnguyen123 commented Aug 3, 2019

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
Copy link

@bertonha bertonha commented Aug 15, 2019

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
Copy link

@karisN karisN commented Aug 27, 2019

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
Copy link
Member

@benhillis benhillis commented Aug 29, 2019

This should be much better in build 18970.

@benhillis benhillis added fixedininsiderbuilds wsl2 and removed fixinbound labels Aug 29, 2019
@onomatopellan
Copy link

@onomatopellan onomatopellan commented Aug 30, 2019

@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
Copy link

@Biswa96 Biswa96 commented Aug 30, 2019

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

@onomatopellan
Copy link

@onomatopellan onomatopellan commented Aug 30, 2019

@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
Copy link

@onomatopellan onomatopellan commented Aug 30, 2019

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

@benhillis
Copy link
Member

@benhillis benhillis commented Aug 30, 2019

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

@eriky
Copy link

@eriky eriky commented Sep 29, 2020

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

sudo hwclock -s

@tommiv
Copy link

@tommiv tommiv commented Sep 29, 2020

@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
Copy link

@danwhitston danwhitston commented Sep 29, 2020

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
Copy link

@janfrederik janfrederik commented Oct 13, 2020

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

@onomatopellan
Copy link

@onomatopellan onomatopellan commented Oct 13, 2020

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

@anthony-steele-cko
Copy link

@anthony-steele-cko anthony-steele-cko commented Oct 14, 2020

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
Copy link

@kevinbosman kevinbosman commented Oct 14, 2020

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

@YoraiLevi
Copy link

@YoraiLevi YoraiLevi commented Oct 14, 2020

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
Copy link

@miklevin miklevin commented Oct 15, 2020

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

@einarpersson
Copy link

@einarpersson einarpersson commented Oct 18, 2020

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
Copy link

@grtrout grtrout commented Oct 20, 2020

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
Copy link

@Roritharr Roritharr commented Oct 26, 2020

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

@garyo
Copy link

@garyo garyo commented Oct 26, 2020

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

@airglow923
Copy link

@airglow923 airglow923 commented Nov 16, 2020

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
Copy link

@tomqwpl tomqwpl commented Dec 3, 2020

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.

@jasonatball
Copy link

@jasonatball jasonatball commented Dec 3, 2020

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
Copy link

@tomqwpl tomqwpl commented Dec 3, 2020

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

@jasonatball
Copy link

@jasonatball jasonatball commented Dec 3, 2020

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.

@ryanatball
Copy link

@ryanatball ryanatball commented Dec 3, 2020

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

@Mereep
Copy link

@Mereep Mereep commented Dec 7, 2020

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
Copy link

@jurij jurij commented Dec 16, 2020

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

@davystrong
Copy link

@davystrong davystrong commented Dec 28, 2020

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-
Copy link

@arcs- arcs- commented Jan 4, 2021

Bump?

@tomqwpl
Copy link

@tomqwpl tomqwpl commented Jan 4, 2021

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
Copy link

@pauljfx pauljfx commented Jan 5, 2021

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
Copy link

@RoyPour RoyPour commented Jan 14, 2021

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
Copy link

@OscBacon OscBacon commented Jan 30, 2021

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
Copy link

@sjschultze sjschultze commented Feb 5, 2021

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.

@microsoft microsoft locked and limited conversation to collaborators Feb 5, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
wsl2
Projects
None yet
Development

No branches or pull requests