Sleep awake early in windows/WSL

[lazytiger]

Version
List the versions of all tokio crates you are using. The easiest way to get
this information is using cargo tree subcommand:

cargo tree | grep tokio

tokio v1.49.0

Platform
The output of uname -a (UNIX), or version and 32 or 64-bit (Windows)

Linux Hoping 6.6.87.2-microsoft-standard-WSL2 #1 SMP PREEMPT_DYNAMIC Thu Jun 5 18:30:46 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

Description
Enter your issue details here.
One way to structure the description:

[short summary of the bug]

I tried this code:

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    init_tracing();
    tokio::time::sleep(Duration::from_millis(1)).await;
    let now = Instant::now();
    let until = now + Duration::from_millis(8888);
    tracing::info!("sleep now");
    tokio::time::sleep_until(until).await;
    tracing::info!("sleep {} ms", now.elapsed().as_millis());
    Ok(())
}

[code sample that causes the bug]

I expected to see this happen: [explanation]

(base) hoping@Hoping:~/CLionProjects/stock$ cargo run --package stock --bin mc
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.08s
     Running `target/debug/mc`
2026-02-26T05:24:34.296322Z  INFO mc: src/bin/mc.rs:22: sleep now
2026-02-26T05:24:43.187451Z  INFO mc: src/bin/mc.rs:24: sleep 8891 ms
(base) hoping@Hoping:~/CLionProjects/stock$ cargo run --package stock --bin mc
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.10s
     Running `target/debug/mc`
2026-02-26T05:35:00.550643Z  INFO mc: src/bin/mc.rs:22: sleep now
2026-02-26T05:35:09.443141Z  INFO mc: src/bin/mc.rs:24: sleep 8892 ms

Instead, this happened: [explanation]

(base) hoping@Hoping:~/CLionProjects/stock$ cargo run --package stock --bin mc
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.53s
     Running `target/debug/mc`
2026-02-26T05:21:18.047576Z  INFO mc: src/bin/mc.rs:22: sleep now
2026-02-26T05:21:25.497163Z  INFO mc: src/bin/mc.rs:24: sleep 8891 ms

This issue is not guaranteed to be reproducible. The pattern I have observed so far is that it occurs after WSL has been idle for a period of time, yet at least one WSL session remains connected. Running this test code then triggers the issue; however, subsequent attempts to reproduce it fail. I am uncertain whether this is a bug in WSL or in Tokio.

EDIT: If you run with time command, you have a big chance to reproduce it.

[lazytiger]

Wsl problem.

[Darksonn]

I don't understand what the problem was to begin with. Did it sleep for too long?

[lazytiger]

@Darksonn Usually, it wakes up too early. Later, I discovered that my WSL had enabled time synchronization, constantly adjusting the time forward or backward. After disabling time synchronization, it was resolved.