# Move parts of \`SystemTime\` into core? **URL:** \ **Category:** libs\ **Created:** [February 17, 2020, 2:40pm UTC](https://internals.rust-lang.org/t/move-parts-of-systemtime-into-core/11844 "2020-02-17T14:40:00Z")\ **Posts on this page:** 5\ **Page:** 2
**Author:** ![jhpratt](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jhpratt/32/11640_2.png) [@jhpratt](https://internals.rust-lang.org/u/jhpratt)\ **Post date:** [February 21, 2020, 6:16am UTC](https://internals.rust-lang.org/t/move-parts-of-systemtime-into-core/11844/21 "2020-02-21T06:16:26Z")
> [@bascule](#): > > My use case for this would be getting the time from an SRTC and using it with e.g. credential libraries which check a credential is still valid given the current time. Ideally I'd like to also work with libraries which obtain the current time (via NTP and/or Roughtime) and use it to update/sync the SRTC to external time sources. How would that work with `SystemTime`, though? Sure, it's possible to have an underlying representation be whatever (irrelevant imo), but there is `SystemTime::UNIX_EPOCH`, which is the only reference value. Without the ability to get that, I wouldn't think there's any particular way to use a `SystemTime` meaningfully, as no information can be extracted. NTP or a STRC are situations where you _might_ be able to _calculate_ the epoch value, but it certainly wouldn't be statically knowable, given the nature of the time source. > [@bascule](#): > > Sidebar: I have attempted to use `chrono` + `no_std` , but found it problematic for a few different reasons, most notably [a Cargo bug which activates the `std` feature in `chrono` if any of your build dependencies use `chrono` with the `std` feature activated](https://github.com/rust-lang/cargo/issues/4866). That's probably not the greatest reason to put `SystemTime` in `core` , but without it fixed `chrono` + `no_std` is pretty painful. Yeah, that just sounds like a bug in Cargo. Definitely an odd one. I wonder how hard that is to fix, given it's been open for a couple years. NB: I haven't yet read through the comments on that issue ---
**Author:** ![derekdreery](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/derekdreery/32/2632_2.png) [@derekdreery](https://internals.rust-lang.org/u/derekdreery)\ **Post date:** [February 21, 2020, 4:27pm UTC](https://internals.rust-lang.org/t/move-parts-of-systemtime-into-core/11844/23 "2020-02-21T16:27:51Z")
Would the time you use in a control-system algorithm be 1. `Instant`, based on a processor clock and therefore guaranteed monotonic (or at least assumed monotonic, ignoring hardware faults and counter overflows) 2. `SystemTime`, which might go backwards if an administrator changes the system clock value? If you control the administration of a computer I would assume that you could prevent problems with (2). ---
**Author:** ![bascule](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/bascule/32/3057_2.png) [@bascule](https://internals.rust-lang.org/u/bascule)\ **Post date:** [February 21, 2020, 5:55pm UTC](https://internals.rust-lang.org/t/move-parts-of-systemtime-into-core/11844/24 "2020-02-21T17:55:40Z")
> [@jhpratt](#): > > How would that work with `SystemTime` , though? Sure, it's possible to have an underlying representation be whatever (irrelevant imo), but there is `SystemTime::UNIX_EPOCH` , which is the only reference value. Without the ability to get that, I wouldn't think there's any particular way to use a `SystemTime` meaningfully, as no information can be extracted. As I mentioned, I would like to be able to use external time sources like NTP and/or Roughtime to obtain the current wall time, and correlate that with an SRTC timestamp (more or less an `Instant`). Are you implying `SystemTime::UNIX_EPOCH` wouldn't be available? Per the OP it sounded like it would. If it is available, it can be used as the anchor by which Roughtime/NTP libraries represent the current wall time, and once there is a correlated pair of SRTC and externally computed `SystemTime`, further `SystemTime` values can be computed as a `Duration` offset from the SRTC's `Instant` where an external `SystemTime` was obtained. I wanted to go back to this though: > Sure, it's possible to have an underlying representation be whatever (irrelevant imo), The big problem right now is there's no common representation `no_std` libraries can use for wall time. To do what I just described I'd need a Roughtime library, and NTP library, and one or more libraries for verifying credentials are unexpired (e.g. X.509 + AuthZ tokens). `chrono` is probably the best bet right now, but as I already mentioned [using it within the embedded ecosystem has been problematic](https://github.com/rust-embedded/cortex-m-rt/issues/60) to the point it was [removed from `cortex-m-rt`](https://github.com/rust-embedded/cortex-m-rt/commit/d8129387234b4e666f29f91bff46d5cb0ab2cfb7). ---
**Author:** ![jhpratt](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jhpratt/32/11640_2.png) [@jhpratt](https://internals.rust-lang.org/u/jhpratt)\ **Post date:** [February 21, 2020, 6:27pm UTC](https://internals.rust-lang.org/t/move-parts-of-systemtime-into-core/11844/25 "2020-02-21T18:27:28Z")
> [@bascule](#): > > As I mentioned, I would like to be able to use external time sources like NTP and/or Roughtime to obtain the current wall time, and correlate that with an SRTC timestamp (more or less an `Instant` ). Yes, that would certainly be possible. > [@bascule](#): > > Are you implying `SystemTime::UNIX_EPOCH` wouldn't be available? Per the OP it sounded like it would. If it is available, it can be used as the anchor by which Roughtime/NTP libraries represent the current wall time, and once there is a correlated pair of SRTC and externally computed `SystemTime` , further `SystemTime` values can be computed as a `Duration` offset from the SRTC's `Instant` where an external `SystemTime` was obtained. That is my implication, yes. At least from my admittedly limited knowledge on the internals of operating systems and hardware interop, most hardware maintains a timestamp from a fixed epoch. As the epoch is fixed, it can be _statically_ calculated when 1970-01-01 0:00:00 is, in terms of the number of seconds relative to the hardware's epoch. A TRC, as far as I am aware, does not have such a fixed epoch. Wouldn't the software then have to _calculate_ when the Unix epoch is, as opposed to it being the `const` that it is now? It could do this trivially — it's just a simple linear in the equation in the form of `y = mx + b`, where `m` is the clock tick speed and `b` is the difference between the hardware epoch and the software (Unix) epoch. Given the nature of a RTC, is it not the case that `b` is not statically known? > [@bascule](#): > > The big problem right now is there's no common representation `no_std` libraries can use for wall time. To do what I just described I'd need a Roughtime library, and NTP library, and one or more libraries for verifying credentials are unexpired (e.g. X.509 + AuthZ tokens). That would certainly be an issue. I think it would depend on whether my above thinking is true or not. If you're right, it shouldn't be too difficult to do this. * * * Note that I'm not opposed to bringing `SystemTime` into `std` on philosophical grounds; on the contrary I believe it would be great to do so. It's just that `UNIX_EPOCH` being a constant causes issues, as far as I can tell. `Instant` would be a much easier addition. I could very well be wrong on any or all this, as I have extremely limited experience working with embedded, and none with RTCs. Feel free to correct me on anything I'm wrong on! I'm took over the time crate a while back; I wouldn't be opposed to adding in additional functionality for `#![no_std]` as a testing ground for `std` if it turns out to be feasible. ---
**Author:** ![system](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/system/32/14092_2.png) [@system](https://internals.rust-lang.org/u/system)\ **Post date:** [May 21, 2020, 6:27pm UTC](https://internals.rust-lang.org/t/move-parts-of-systemtime-into-core/11844/26 "2020-05-21T18:27:36Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed. [Previous page](https://internals.rust-lang.org/t/move-parts-of-systemtime-into-core/11844.md?page=1)