Re: Clarification of CLOCK_MONOTONIC

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Mon, 8 Jun 2026 13:17:11 +0000
    From:        Taylor R Campbell <riastradh%NetBSD.org@localhost>
    Message-ID:  <20260608131712.D059684CD8%mail.netbsd.org@localhost>

  | I think it is arguable whether CLOCK_MONOTONIC _should_ include or
  | exclude time suspended.  I'm not sure NetBSD is currently consistent
  | across ports about this.

I suspect it is clear that POSIX intends it to be, but I'm not sure
they have any notion of, or even considered the possibility of, a system
being suspended, and what that would mean.

I'm also not sure it is actually possible to implement as required over
suspensions - I mean, how does a system without a RTC (that keeps running)
manage to work out how long it was suspended?   It can (eventually) use
NTP (or a connected GPS, or similar) to discover the correct time, but
in the interval between when the suspension ends, and when the correct
time is determined, accesses to CLOCK_MONOTONIC still need to work.
I guess one could end a period of suspension, and only re-enable a
process to correct the time, and then enable the rest of the system
to run after that completes, but what if it doesn't?  The system might
have been suspended while it was carried into a deep cave, no access
to any surface radiowaves at all, no way to get the correct new time.

Further, even with a RTC, those things are rarely very accurate, and
after a suspension that lasts for weeks, or perhaps months, it is
entirely possible it will run faster than actual time, meaning that
either the monotonic clock needs to go backwards (if the RTC time difference
from after - before the suspend is used to determine how much time
passed), which isn't allowed, or stop counting for a while (which isn't
allowed either, at least if any other clocks are counting, as they would
make it obvious that time is passing, while the monotonic clock isn't
advancing, and so isn't counting seconds since the reference point) - the
same if it just counts more slowly (stops actually counting seconds) for
a period.

But then the POSIX people have never given the impression that they
understand anything about time (and I mean even as most of us seem to
understand it, not Einstein's quantum stuff) so that all of this is
screwed up is hardly a big surprise.

  | * POSIX.1-2024

  |   . maximum possible clock jump shall be implementation-defined and
  |     must be documented

I saw this in their <time.h> spec, and can't imagine what that is
trying to achieve, nor what exactly they are attempting to define,
or why.   If they mean the resolution of the clock, that's a strange
way to describe it.

But what is supposed to be limited is hard to fathom - if they mean the
biggest difference allowed between the results from two
clock_gettime(CLOCK_MONOTONIC) calls, which the definition of Clock Jump
in XBD 3.67 would seem to suggest, then the only possible definable maximum
jump would be infinite, which makes no sense to define.

Further, no matter what test was developed, to attempt to detect exceeding
some other defined maximum, any difference that seems to be beyond what
is allowed can be explained by simply explaining (claiming) that there
were N smaller jumps (each less than the allowed maximum) which occurred,
and the test simply failed to observe the intermediate states.

  |   . reference point does not change after system start-up time

The ambiguity there is what is "system start-up time" - one could
say that when the system is suspended it is stopped (after all, nothing
is running) and so when it resumes, it is starting (again) and hence
a new reference point can be established.   Useless, but possible.

As best I can determine POSIX has no definition for what that means.

kre