systemd-timesyncd seems default on Debian, but it is not on CentOS. That doesn’t mean we couldn’t mimic its behaviour (or that of cronky or ntpd) but if we do we should make sure that the results are only used (if at all) after the clock has been set in a safe way, which is the first thing to solve.
Given that the alternatives to systemd-timesyncd are probably more stand-alone it might be more difficult to fake systemd-timesyncd behaviour than the behaviour of other tools.
A sclockadj3 should IMO be based on the simplest alternative from ntpd/cronky/systemd-timesyncd/other code that can actually run without doing unsafe NTP protocol based time queries (or if they are done, discard them, or only use them as a check, not as a source). Simplest in the sense of lines of code, because that leads to the smallest package to maintain, iff we have to make changes at all. E.g. chrony (at 32KLOC about a tenth of ntpd), claims that it can run from manual input. In case manual input always makes the clock jump we could probably emulate a GPS receiver without PPS (through gpsd, but then gpsd source is about 52KLOC)
Going that route, instead of reimplementing the interaction with the kernel as tried in slockadj2 is AFAIKT now much simpler.
