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

Open
erdemece opened this issue Jun 29, 2019 · 48 comments
Open

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

erdemece opened this issue Jun 29, 2019 · 48 comments
Assignees

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

Copy link

@lmatter lmatter commented Jul 2, 2019

Me too.

@cxsy

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

Copy link
Member

@benhillis benhillis commented Aug 29, 2019

This should be much better in build 18970.

@onomatopellan

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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.

@Kai-Richardson

This comment has been minimized.

Copy link

@Kai-Richardson Kai-Richardson commented Sep 16, 2019

This has been fixed on my machine using previous error case (sleeping) as of build 18980.

@ricardosantos9521

This comment has been minimized.

Copy link

@ricardosantos9521 ricardosantos9521 commented Oct 22, 2019

This is happening in build 19002 after the pc is suspended for long hours. wsl.exe --shutdown is the fix

@johnmcdowall

This comment has been minimized.

Copy link

@johnmcdowall johnmcdowall commented Oct 30, 2019

Just ran into this in build 19008.1000. sudo hwclock -s fixed it.

@ricardosantos9521

This comment has been minimized.

Copy link

@ricardosantos9521 ricardosantos9521 commented Nov 8, 2019

I think this is not fixed, since i have to do sudo hwclock -s almost every day morning (after 7/8 hours of suspending the pc). So please fix this. This happen after my surface laptop 1 is suspended for multiple hours.

image

image

P.S: I think this is happening when i have vscode attached to wsl

@Rhahkeem

This comment has been minimized.

Copy link

@Rhahkeem Rhahkeem commented Nov 8, 2019

Same as above . This still happens for me with vscode too

@benhillis

This comment has been minimized.

Copy link
Member

@benhillis benhillis commented Nov 8, 2019

Any output in dmesg?

@ricardosantos9521

This comment has been minimized.

Copy link

@ricardosantos9521 ricardosantos9521 commented Nov 8, 2019

[Thu Nov  7 23:09:15 2019] rtc_cmos 00:00: setting system clock to 2019-11-07 19:09:44 UTC (1573153784)
[Thu Nov  7 23:09:15 2019] Unstable clock detected, switching default tracing clock to "global"
                           If you want to keep using the local clock, then add:
                             "trace_clock=local"
@benhillis

This comment has been minimized.

Copy link
Member

@benhillis benhillis commented Nov 8, 2019

@ricardosantos9521 - thanks, those events are not relevant, anything about not being able to translate timezone? What is the output of readlink /etc/localtime?

@ricardosantos9521

This comment has been minimized.

Copy link

@ricardosantos9521 ricardosantos9521 commented Nov 8, 2019

No it doesn't appear nothing related to timezone translation.

readlink /etc/localtime returns (that is my timezone):
/usr/share/zoneinfo/Europe/Lisbon

@benhillis

This comment has been minimized.

Copy link
Member

@benhillis benhillis commented Nov 8, 2019

@ricardosantos9521 - Ok, and does sudo hwclock -s get you back in sync?

@ricardosantos9521

This comment has been minimized.

Copy link

@ricardosantos9521 ricardosantos9521 commented Nov 8, 2019

Yes it does, until the next day morning

@miklevin

This comment has been minimized.

Copy link

@miklevin miklevin commented Nov 14, 2019

Yes it does, until the next day morning

This is my experience too. I have to sudo hwclock -s every day. Not cool.

@benhillis

This comment has been minimized.

Copy link
Member

@benhillis benhillis commented Nov 14, 2019

@miklevin - In your case, how much does your clock drift? To be clear, we're working on a fix for this, I'm just presenting some workarounds in the meantime (wsl.exe --shutdown is very heavy-handed).

@ricardosantos9521

This comment has been minimized.

Copy link

@ricardosantos9521 ricardosantos9521 commented Nov 14, 2019

I want to add some new things. I think this is related to the way that suspension works (in this case on my surface laptop). After some hours of suspension (appears to be arround 4 hours) the pc goes to a kind of hibernation (windows animation appears, instead of going directly login screen) instead of continuing in suspension. So when i awake the pc in this 4 hours interval the clock appears to be ok. After that interval the clock starts to drift.
So the drift in my case appears to be related to this 4 hours. If i suspended my pc at 1pm it appears that the clock will work until 5pm after that the clock starts to drift.

@benhillis

This comment has been minimized.

Copy link
Member

@benhillis benhillis commented Nov 14, 2019

@ricardosantos9521 - Thanks for the additional info. If you don't mind, could you describe your config? Are you using WSL2 nested? What kind of hardware are you using?

@ricardosantos9521

This comment has been minimized.

Copy link

@ricardosantos9521 ricardosantos9521 commented Nov 14, 2019

I am runing Windows Fast Ring Builds as my main and unique os in a Surface Laptop 1 (i5-7200U) with all the default configs for WSL2. I am running Ubuntu from the Store.

@johnmcdowall

This comment has been minimized.

Copy link

@johnmcdowall johnmcdowall commented Nov 18, 2019

FWIW it was super clear to me that the amount of time that the Ubuntu clock drifted was exactly the amount of time my laptop had been closed shut and sleeping. On wake WSL is not re-syncing the clock for whatever reason. Running sudo hwclock -s fixes the time to be the correct time and is fine until the next time you sleep your machine.

@nicolashopin

This comment has been minimized.

Copy link

@nicolashopin nicolashopin commented Nov 24, 2019

Same issue on a Dell XPS on the slow build. Definitely related to sleep

@timbophillips

This comment has been minimized.

Copy link

@timbophillips timbophillips commented Nov 25, 2019

I have the same issue DEll XPS 13 7390 Windows Build 19030.1

@jaimergp jaimergp mentioned this issue Dec 1, 2019
5 of 5 tasks complete
@benhillis

This comment has been minimized.

Copy link
Member

@benhillis benhillis commented Dec 2, 2019

If somebody is able to reproduce this could you please run powercfg /spr and share the contents?

@marrobi

This comment has been minimized.

Copy link
Member

@marrobi marrobi commented Dec 5, 2019

Same here, 19033 - @benhillis have emailed you my report.

@noelbundick

This comment has been minimized.

Copy link
Member

@noelbundick noelbundick commented Dec 7, 2019

+1, another report in your inbox @benhillis

@miklevin

This comment has been minimized.

Copy link

@miklevin miklevin commented Dec 12, 2019

Another report in your inbox @benhillis

@myxoh

This comment has been minimized.

Copy link

@myxoh myxoh commented Jan 18, 2020

Any ETA on a potential fix?

@benhillis

This comment has been minimized.

Copy link
Member

@benhillis benhillis commented Jan 18, 2020

Issue is being debugged, in the meantime I suggest using "sudo hwclock -s" as needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.