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

More methods for std::time::Duration #1917

Open
clarfonthey opened this issue Feb 21, 2017 · 5 comments
Open

More methods for std::time::Duration #1917

clarfonthey opened this issue Feb 21, 2017 · 5 comments
Labels
T-libs-api Relevant to the library API team, which will review and decide on the RFC.

Comments

@clarfonthey
Copy link
Contributor

Right now, we have:

  • from_secs
  • from_millis
  • as_secs
  • subsec_nanos

It'd be nice if we also had:

  • from_hours (note: potential for overflow)
  • from_mins (note: potential for overflow)
  • from_micros
  • from_nanos
  • as_hours
  • as_mins
  • subsec_millis
  • subsec_micros

And potentially also:

  • from_days (note: potential for overflow)
  • as_days
  • as_millis (note: potential for overflow)
  • as_micros (note: potential for overflow)
  • as_nanos (note: potential for overflow)

(Note that as_millis is already suggested by #1545).

time::Duration already has a lot of these, and it'd be nice if the libstd version did too. These don't seem that hard to implement or maintain, and they seem useful enough to have.

@polyfloyd
Copy link

Yes, time::Duration is lacking quite some functionality.

Go uses constants to work with durations. Maybe we could introduce this idea in Rust:

let four_seconds = time::SECOND * 4;

let five_hundred_millis = time::MILLISECOND * 500;

let one_and_a_half_second = time::SECOND + time::SECOND / 2;

let one_day = time::HOUR * 24;

Similarly, as_* could be realized by division and subsec_* by the remainder.

@nagisa
Copy link
Member

nagisa commented Mar 17, 2017 via email

@mqudsi
Copy link

mqudsi commented Apr 30, 2017

The reason why these larger, more-confusing units should be included (IMHO) is precisely because they are hard to get right. I think C#'s TimeSpan is a good model for Duration; it provides an easy way to go from logical units to system time and abstracts away all the things that could go wrong. Conversation to and from "higher order" units via the from_xxx and as_xxx methods is a great boon to developers of "real" software, and if implemented properly, could save a whole class of problems for developers down the road.

If this should not be included in core, there should at least be a blessed crate for this; already there is a huge and unwieldy gap between std and the time crate, which is a source of enormous confusion to the entire community.

@withoutboats withoutboats added the T-libs-api Relevant to the library API team, which will review and decide on the RFC. label May 14, 2017
@scottmcm
Copy link
Member

scottmcm commented Feb 4, 2018

Some of these seem to be open as rust-lang/rust#47097

@pickfire
Copy link
Contributor

Why is only as_hours() using the long form as compared to the others? What if others typed as_hrs()? Will the error redirect to as_hours()?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-libs-api Relevant to the library API team, which will review and decide on the RFC.
Projects
None yet
Development

No branches or pull requests

7 participants