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
CLOCK_MONOTONIC,

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:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/src/c%2B%2B11/chrono.cc;h=8f869df5696473ebd0157e9edb4875af8c1381ce;hb=HEAD#l50

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