On Thu, 20 Apr 2023 at 11:55, Andrey Semashev via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
On 4/20/23 13:12, Jonathan Wakely wrote:
> On Thu, 20 Apr 2023 at 08:45, Andrey Semashev via Std-Proposals
> <std-proposals@lists.isocpp.org <mailto:std-proposals@lists.isocpp.org>>
> wrote:
>     I wanted to say that I faced this problem as well, and my solution was
>     to define clock traits that, among other things, allowed to know the
>     clockid_t corresponding to a given chrono clock.
> User code can't know this, certainly not as a compile-time constant. It
> might depend on runtime conditions, such as the kernel version the
> application runs on, and the system config.

Well, all kernel versions we cared to support do support

As Thiago mentioned, chrono::steady_clock could potentially use CLOCK_MONOTONIC_RAW, and the decision to use it could be made at runtime (by trying it once and if the syscall returns ENOSYS using CLOCK_MONOTONIC for all future calls).

and CLOCK_REALTIME is mandatory on all POSIX systems.

But even that isn't always used, and the decision of whether to use it might depend on the version of the std::lib that you dynamically link to at runtime:

A compile-time constant in the headers cannot accurately represent that behaviour.