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