Rust internals debates a global time source for wasm targets

A tiny gap in time handling keeps turning into real work for Rust-on-wasm code. The June 3 Rust Internals discussion asks whether Rust should grow something like `#[global_allocator]`, but for time, so `std::time::Instant::now()` could route through a selectable global source instead of hard-coding one behavior for every target.

Why this hurts more than it looks

On `wasm32-unknown-unknown`, the standard library is present, but plenty of the usual assumptions break down. Rust’s target docs are blunt about it: `println!` can do nothing, `std::fs` can return errors, and `std::thread::spawn` can panic. The target is meant to be self-contained and aimed at use cases that do not depend on imported functionality, which means the platform boundary is real, not accidental.

That boundary becomes especially visible with time. In native Rust, `Instant::now()` and `SystemTime::now()` feel like boring primitives. In wasm, they become a source of friction because the host decides what time even means, and sometimes the answer is “not available through `std`.”

The ecosystem already has to paper over the gap

The most practical sign that this is a real pain point is that crates already exist to replace the standard library’s time APIs. `web-time` presents itself as a drop-in replacement for `std::time` in browsers, and it wires `Instant` to `Performance.now()` and `SystemTime` to `Date.now()`. It also documents a harder edge: on `wasm32-unknown-unknown`, `Instant::now()` and `SystemTime::now()` will panic unless you swap in the crate.

There is also a useful wrinkle for more advanced builds. `web-time` says atomics-enabled builds can synchronize timestamps across contexts such as web workers, which matters when you are trying to line up behavior across multiple execution environments. Older codebases often reach for `instant`, which emulates `std::time::Instant` on `wasm32-unknown-unknown` using JavaScript `performance.now()` when its wasm-related features are enabled. That is exactly the kind of workaround that gets the job done while quietly spreading a second, parallel time API through a codebase.

The result is familiar to anyone maintaining portable Rust: application authors swap types by hand, library maintainers end up choosing a wasm-specific abstraction up front, and test setups get awkward because the timing source is no longer a normal process clock. A library that only wanted to measure elapsed time suddenly has to know whether it is running in a browser, under a worker, or somewhere else entirely.

What a global time source would change

The appeal of the proposal is not subtle. A global time hook would let a crate provide one type or implementation and select it centrally, instead of forcing scattered substitutions everywhere `Instant` appears. That is the same ergonomic win that `#[global_allocator]` gives memory management: one choke point, one configuration decision, fewer local compromises.

That matters because time is not just a utility. In Rust code, it feeds scheduling, retries, benchmarking, timeout logic, deterministic testing, and async runtimes. If the standard library offered a clean hook, then crates like `web-time` or `instant` could become providers of a global source rather than stand-ins that require every caller to remember a different type.

For portable crate design, that could be a real simplification. Today, a library author who wants wasm support often has to choose between staying purely `std`-shaped and giving up on correct behavior, or adding a crate-specific abstraction that bleeds into public APIs. A global hook would reduce that pressure and make it easier to write one API surface that behaves sensibly on native and wasm targets alike.

The hard part is semantics, not plumbing

The challenge is that time on wasm is not one thing. A browser’s wall clock, a monotonic timer, a worker context, and a sandboxed runtime do not all behave the same way, and the June 3 thread sits inside a longer Rust debate about how much the standard library should know about host-specific reality. The wrong abstraction would be worse than no abstraction if it makes code think it has wall-clock guarantees that the host never offered.

That tension has come up before. A 2022 Rust Internals discussion about whether `std::time::Instant` on WebAssembly was possible pointed out that wasm hosts differ, with the web, Emscripten, and WASI each providing time support differently. It also highlighted why `wasm-bindgen` is awkward as a dependency boundary: it lives outside the Rust toolchain and generates JavaScript glue, so baking that into `std` would be a mess.

So the question is not whether Rust needs better wasm time handling. It already does, and the crates prove it. The question is whether the standard library should offer a privileged override that keeps portability intact without making timing semantics fuzzy.

Part of a larger wasm argument

This debate also sits inside a broader frustration with wasm support in Rust. Rust has supported `wasm32-unknown-unknown` since 2017, but community discussions in 2024 and February 2026 show that people still feel the target story is uneven, especially when new wasm builtins and host assumptions start creeping into code generation and runtime behavior. Those conversations make the time-source proposal feel less like a niche convenience and more like one more attempt to make Rust’s abstractions match how wasm actually works in practice.

That is why the idea has traction. It targets a small systems-level gap that spills into daily developer pain, and it does so without asking every crate to reinvent its own wasm story. If Rust can make time as pluggable as allocation, one of the most annoying seams in portable crate design gets a lot less visible, and wasm stops feeling like the place where `Instant` quietly turns into a project-wide rewrite.