core::time::Durationand re-export it as
core::time::SystemTimeand re-export it as
core::time::UNIX_EPOCHand re-export it as
std::time::SystemTime::now(), replacing it with a standalone
std::time::SystemTime::elapsed(). Users would be encouraged to use
In the future, we might move
std::time::Instant to libcore. This is out of the scope of this proposal.
In the future, we might provide some pluggable interface so that an application and/or platform port can provide its own implementation of the
std::time::now(). This is out of the scope of this proposal.
This proposal is not adding any new functionality; it is just exposing some more functionality from libcore that’s already exposed from libstd.
Some crates want to be able to compare times without depending on libstd, so that they can work with the
#[no_std] feature. Exposing the functionality for comparing times from libcore is helpful for this. Concrete examples include my webpki crate and some other crates I am developing. I believe this would eventually be useful for rustls and many other crates. Rust operating systems might even be able to use these types as their native time/duration types.
libcore/libstd doesn’t necessarily know how to get the current time (in UTC) on every platform, and libstd might not be available. But, the application may have a way of getting the current system time (in UTC), in which case it can construct a
SystemTime itself. (Consider, for example, a network of IoT devices where only one trusted device knows what time it is, and other devices on the network fetch the time from it.) Or, the application may not need to do time comparisons based on the current time, but rather only on two explicitly-given times, in which case
elapsed() are not needed. This is why they would stay libstd-only. For now, it is expected that
#![no_std] applications would construct a
SystemTime by adding some
UNIX_EPOCH, where the
Duration is constructed by some non-libcore/libstd API that returns the current time as an integer (milliseconds or whatever) relative to the (or some) epoch.
This subset of the API is a good fit for libcore because it is self-contained. In particular, it doesn’t depend on the memory allocator or other things that aren’t normally present in libcore. Since the code is platform-independent, this proposal doesn’t make it harder to port libcore. Applications that don’t use this functionality won’t be (negatively) affected by it.
libstd would still need to provide
std::time::SystemTime::elapsed() for backward compatibility, which means that exposing
std::time::SystemTime wouldn’t be as simple as
pub use core::time::SystemTime. However, I assume there’s already some mechanism for doing this that’s already considered acceptable for other uses.
A crate that doesn’t want to depend on libstd could, in theory, use traits and/or other abstraction mechanisms to provide an API that accepts
std::time::SystemTime or some other kind of time. Then
#![no_std] uses of the crate would use the trait. I experimented with doing this in one crate (webpki), and it can be made to work, but it isn’t as clean as just having
SystemTime always available.
Thank you for taking the time to review this proposal.