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.
e.g. std::chrono::tai_clock might use Linux's CLOCK_TAI if the kernel supports it, and if the kernel's tai offset "roughly correct" (i.e. some system process like chrony has actually adjusted the tai offset, rather than leaving it at zero which is the value on boot). That is something that can only be detected at runtime inside the std::lib.
Also, in that code base
we defined our own clock types that explicitly use clock_gettime with
various clock id constants, and we don't use std::chrono clocks at all.
Granted, that code base is mostly Linux-only, and definitely not
compatible to Windows. It may run on other POSIX systems, but it was
On 4/20/23 03:20, Thiago Macieira via Std-Proposals wrote:
> In refactoring some older Qt code that directly used clock_gettime() to use
> std::chrono::steady_clock, I stumbled upon a limitation: I need to pass clock
> time points to certain low-level functions. The one in particular I was
> looking at is pthread_cond_timedwait(), whose timestamp must match the POSIX
> clock set with pthread_condattr_setclock(). I wrote the code assuming that in
> all systems std::chrono::steady_clock was the same as CLOCK_MONOTONIC, but
> this isn't true in either Darwin systems (libc++ uses CLOCK_MONOTONIC_RAW) or
> QNX (no clue what happens there).
> Therefore, I'd like to propose that steady_clock add an extra method that
> returns the clock ID. It could be as simple as:
> [[pure]] static int clock_base();
I think, it would be better to return clockid_t, and define the type to
int or whatever on platforms that don't define it yet. Returning int
would be suboptimal on (or incompatible with) platforms that define
clockid_t to a different type. It should be strongly implied (perhaps,
in a non-normative note) that this clockid_t type is intended to
correspond to POSIX clockid_t, and the set of supported values matches
the CLOCK_* constants.
Also, clock_id() name seems more appropriate, as the clock type does not
only affect the epoch (base) time point, but also the precision (e.g.
*_COARSE clocks) and time progression (e.g. *_CPUTIME_ID clocks).
Perhaps, it would be even better to add a static constant to a clock
type rather than a static method. This would allow it to use the id in
Then it would have to be given an invalid value for many clocks (including chrono::steady_clock!), because it can't be known at compile-time.