Tracking issue for duration_constants

Implemented in #57375

This will make working with durations more ergonomic. Compare:

// Convenient, but deprecated function.
thread::sleep_ms(2000);

// The current canonical way to sleep for two seconds.
thread::sleep(Duration::from_secs(2));

// Sleeping using one of the new constants.
thread::sleep(2 * SECOND);

impl Duration {
    pub const WEEK: Duration = Duration::from_weeks(1);
    pub const DAY: Duration = Duration::from_days(1);
    pub const HOUR: Duration = Duration::from_hours(1);
    pub const MINUTE: Duration = Duration::from_mins(1);
    pub const SECOND: Duration = Duration::from_secs(1);
    pub const MILLISECOND: Duration = Duration::from_millis(1);
    pub const MICROSECOND: Duration = Duration::from_micros(1);
    pub const NANOSECOND: Duration = Duration::from_nanos(1);
    pub const MAX: Duration = ...;
}

Currently these constants are free constants in the std::time module. I think we should consider moving them onto the Duration type as associated constants.

@stjepang

Associated constants would reduce the (typical) number of imports in code using this. @stjepang @frewsxcv what do you think?

I’ll FCP to merge once this is resolved one way or another.

Rollup merge of rust-lang#58595 - stjepang:make-duration-consts-assoc…

@rfcbot

Updated the issue description.

@rfcbot fcp merge

@SimonSapin

Team member @SimonSapin has proposed to merge this. The next step is review by the rest of the tagged team members:

Concerns:

~~clippy~~ resolved by Tracking issue for duration_constants #57391 (comment)
~~consider unit structs~~ resolved by Tracking issue for duration_constants #57391 (comment)
documentation (Tracking issue for duration_constants #57391 (comment))
~~missed the point~~ resolved by Tracking issue for duration_constants #57391 (comment)

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

Rollup merge of rust-lang#84120 - workingjubilee:stabilize-duration-m…

I was amazed by how long this has been opened.

There are two possibilities
-Associated constants become importable directly (use std::time::Duration::SECOND)
then yes, it will be very ergonomic and handy and should be stabilized.

-Close the issue as why even bother with (Duration::SECOND) when we already have (Duration::from_secs(n))
AND when you want to use it for anything beside a second, lets say 42
(Duration::from_secs(42)) makes no sense to implement (Duration::SECOND * 42).

*Just a mere opinion
If "const" was like "let" so that you don't have to always specify a type, I think, again, this issue would be closed in favor of...

at worst, Duration is not in scope
const SECOND = std::time::Duration::from_secs(1);

instead of
const SECOND:std::time::Duration = std::time::Duration::from_secs(1);

At best
const SECOND = Duration::from_secs(1);

Is there a particular reason this still isn't in a FCP? It's been over 6 years, and this is a relatively small change.

I think that they should not use full names because I am bad at spelling MILLISECONDS.
I think that the best option is to use SI abbreviations, like MS or S or US.
If we are using full names, there should be both plural and singular versions (eg MILLISECOND and MILLISECONDS) because sleep(2*MILLISECOND) or sleep(1*MILLISECONDS) look weird.

Ideally it would be properly capitalized SI abbreviations (like ms, not `MS'), but the convention says that constants should be uppercase, and I want to keep it that way.

We discussed this in the libs meeting - if someone would put up a stabilisation PR (and improve the docs to give usage examples, with the appropriate directive to ensure tests don't actually wait for n * Duration::SECOND) we're happy to FCP that. thanks!

Rollup merge of rust-lang#163138 - sorairolake:feature/more-duration-…

Unrolled build for #163138 in rollup 163165

Navigation Menu

Repository navigation

Tracking issue for duration_constants #57391

31 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking issue for duration_constants #57391

Description

Activity

oli-obk commented on Jan 7, 2019

SimonSapin commented on Feb 1, 2019

SimonSapin commented on Feb 27, 2019

rfcbot commented on Feb 27, 2019

31 remaining items

Ahmad-34567890 commented on Mar 27, 2023

Aandreba commented on Mar 29, 2023

zdivelbiss commented on Jul 14, 2025

Velocifyer commented on Jul 22, 2026

nia-e commented on Aug 11, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions