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 · 3 comments

Feature request: time::now #62114

yoshuawuyts opened this issue Jun 25, 2019 · 3 comments


Copy link

@yoshuawuyts yoshuawuyts 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:

Copy link

@jethrogb jethrogb 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.

Copy link

@sfackler sfackler 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.

Copy link
Member Author

@yoshuawuyts yoshuawuyts commented Sep 16, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants