Why CLOCK_MONOTONIC?

A Unix timestamp (i.e. CLOCK_REALTIME) is always GMT0, so it's not effected by daylight savings. But a "POSIX second" is not the same thing as an SI second as POSIX says there are _exactly_ 86400 seconds per calendar day. That cheat makes calendar arithmetic incredibly simple. But when there's a leap second in UTC, one or more "POSIX seconds" need to be stretched. Thus, if there's a leap second within (or near) the interval between two Unix timestamps, the difference doesn't reflect the number of elapsed SI seconds. Similarly, depending on the skewing algorithm, a single Unix timestamp could represent two SI seconds.

For many engineering use cases what people normally would want is CLOCK_TAI. But, AFAIU, CLOCK_TAI can go backwards if the sysadmin or faulty hardware demands it, so often CLOCK_MONOTONIC is the safest choice to avoid weird arithmetic errors (as opposed to errors from poor accuracy or precision).

There's a movement to remove leap seconds from UTC so that UTC becomes a fixed offset from TAI. IMO that's short-sighted. It doesn't really improve things much as a practical matter (see TAI vs monotonic, above). Nor even as a theoretical matter (see special relativity). Anyhow, if we wanted to ignore the inherent complexity of time synchronization we may as well jump straight to BCT (https://en.wikipedia.org/wiki/Barycentric_Coordinate_Time)