Feature request: time::now

[yoshuawuyts]

Preface: this is the first time I'm filing an issue on rust-lang/rust. This is a feature request that also seems too small for an RFC. The contrib guidelines are not too clear what to do here, so I hope I'm doing this right.

Motivation

In #57391 there's been conversation about making it easier to construct new time::Durations by using constants:

use std::time;

futures_timer::wait_for(30 * time::SECS).await;

While writing code today I was wondering about easier ways to create Instants. Specifically creating a timestamp that evaluates to now would be useful. As it could be combined with the constants to create an Instant at a particular point in the future.

This is why I would like to propose the addition of a time::now function that would be equivalent to time::Instant::now. The result would be for most programs only the top-level std::time module needs to be imported, and lines dealing with time-related code would be fewer to express the same results.

Thanks!

Examples

Adapted from the time::Instant docs.

Proposed

use std::{time, thread};

let now = time::now();
thread::sleep(2 * time::SECS);
println!("{}", now.elapsed().as_secs());

Current

use std::time::{Duration, Instant};
use std::thread::sleep;

let now = Instant::now();
sleep(Duration::from_secs(2));
println!("{}", now.elapsed().as_secs());

edit: I've written a post on this: https://blog.yoshuawuyts.com/std-time/

[jethrogb]

Why Instant::now and not SystemTime::now?

I could ask the same question if this was the opposite proposal. Therefore, I don't think this should be done at all. There is no clear default to choose, so requiring disambiguation makes sense.

[sfackler]

There are very few free-function constructors in the standard library. Many constants are at the module level simply because associated constants weren't stable in 1.0.

[yoshuawuyts]

Closing as I think @jethrogb makes a great point and we shouldn't do this.