steps to reproduce:
- temporarily disable system NTP, eg
systemctl stop systemd-timesyncd
- record the current monotonic timer:
(time-second (current-time 'time-monotonic))
- set the system time backwards,
sudo date -s "@$(($(date +%s) - 3600))"
- record monotonic timer again:
(time-second (current-time 'time-monotonic))
the second value will be less than the first
I expected that "monotonic" in this context meant "never goes backwards," but it seems that the intent is actually just monotonic to the extent of ignoring leap seconds, and will readily go backwards if the underlying OS UTC clock goes backwards
if this is the intended behavior, it should be documented as such. otherwise, using monotonic OS timers (e.g. clock_gettime with CLOCK_MONOTONIC[_RAW] on Unix/Linux) or compensating for any backwards jumps in the underlying OS clock should be the default behavior
steps to reproduce:
systemctl stop systemd-timesyncd(time-second (current-time 'time-monotonic))sudo date -s "@$(($(date +%s) - 3600))"(time-second (current-time 'time-monotonic))the second value will be less than the first
I expected that "monotonic" in this context meant "never goes backwards," but it seems that the intent is actually just monotonic to the extent of ignoring leap seconds, and will readily go backwards if the underlying OS UTC clock goes backwards
if this is the intended behavior, it should be documented as such. otherwise, using monotonic OS timers (e.g.
clock_gettimewithCLOCK_MONOTONIC[_RAW]on Unix/Linux) or compensating for any backwards jumps in the underlying OS clock should be the default behavior