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

Feature request: time::now #62114

yoshuawuyts opened this issue Jun 25, 2019 · 2 comments


None yet
4 participants
Copy link

commented Jun 25, 2019

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.


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.



Adapted from the time::Instant docs.


use std::{time, thread};

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


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

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

edit: I've written a post on this:


This comment has been minimized.

Copy link

commented Jun 25, 2019

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.


This comment has been minimized.

Copy link

commented Jun 25, 2019

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.

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