Move parts of `SystemTime` into core?

[jhpratt]

@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. 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}

[derekdreery]

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).

[bascule]

@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 to the point it was removed from cortex-m-rt.

[jhpratt]

@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.