Hi, I just realized, that Rust std-lib lacks support for different clocks and time-sources, so far std::time does support only some kind of monotonic form of time, but struggling to deliver this promissed functionality. std::time is producing kind of agglutinated clock, a wrapper around the platform specific clocks.
A single clock does not suffice the different needs for HMI and network protocol implmentations.
I am wondering why the std-lib does not offer an API for the different clocks of the platform it is running on, espacially when talking about mobile devices moving between time-zones.
The Rust std-lib should provide access to different clocks, at least similar to C++ std::chrono::system_clock /std::chrono:.steady_clock or for example the different clocks supported by C-API clock_gettime (Monotonic,System, CPU-Local, etc.).
Monotonic/steady clock should be used for RELIABLE network-protocol implementaitons whereas the system-clock may be in sync with GPS and being used to display local times in HMI.
Instant time points should be parameterized by the underlying clock, for example Instant<Clock>, and runtime::now<Clock>() should permit the developers to express the required clock. And frameworks such as Tokio etc. should use timeouts/deadlines only based on Instant<Clock::Monotonic> or Duration<Clock::Monotonic>
Especially talking about mobile devices moving between time-zones and syncing with external clock, Rust should not repeat the bad API design of ancient C-API with a single agglutinated time-source, but should follow newer API-design as demonstrated by C++ std::chrono::system_clock/monotonic_clock or C-API “clock_getttime()”
