Rust: Feature request: time::now

Created on 25 Jun 2019  路  3Comments  路  Source: rust-lang/rust

_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 https://github.com/rust-lang/rust/issues/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/_

C-feature-request T-libs

Most helpful comment

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.

All 3 comments

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.

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.

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

Was this page helpful?
0 / 5 - 0 ratings

Related issues

withoutboats picture withoutboats  路  202Comments

nikomatsakis picture nikomatsakis  路  268Comments

nikomatsakis picture nikomatsakis  路  331Comments

nikomatsakis picture nikomatsakis  路  210Comments

nikomatsakis picture nikomatsakis  路  236Comments