Instant<Clock> and runtime::now<Clock>()

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()”


It supports both monotonic time through Instant, and the system time through SystemTime.

Now, having a second look at the API, I see. Well, seems I was a bit hasty :wink:

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.