On Thursday, 20 April 2023 03:55:04 PDT Andrey Semashev via Std-Proposals
wrote:
> Well, all kernel versions we cared to support do support
> CLOCK_MONOTONIC, and CLOCK_REALTIME is mandatory on all POSIX systems.
> But you have a point for other clock types.

While CLOCK_MONOTONIC is optional with POSIX, it's actually implemented in all
current, POSIX-compatible OSes I know of. In fact, it is easier for the OS to
implement the monotonic clock than the realtime one, because it controls all
access to the RTC and therefore knows that can't go backwards unless it was
mediated by that very OS (even assuming that the clock source is backed by the
RTC).

Whether that clock source is suitable for steady_clock or not is a different
story. The libc++ source code says that only CLOCK_MONOTONIC_RAW is acceptable
for Darwin because it has nanosecond resolution (implying CLOCK_MONOTONIC does
not).

There's always the question of whether such clock should reflect time spend
suspended or not. On Darwin, CLOCK_MONOTONIC is documented to include them,
but not so on Linux; if an implementation wanted to have similar behaviour on
both, it would need to use CLOCK_UPTIME on Darwin or CLOCK_BOOTTIME on Linux.

We should remember though that the C++ standard requires steady_clock with
is_steady = true. So strictly speaking, an implementation without a monotonic
clock can't be C++11-compliant. If I were the C++ library implementers, I'd
remove the fallback code and see what breaks / who complains... we're 12 years
after steady_clock was made mandatory.

This is actually what I changed in Qt this week: I removed support for systems
without CLOCK_MONOTONIC... but then decided to go all in and use steady_clock,
only to see the unit tests fail on QNX for an unknown reason and on macOS
(that was actually my mistake).

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering