OK, here's a summary of what is going on (as far as I can tell):

rcutils_steady_time_now():

Current implementation on Linux uses CLOCK_MONOTONIC_RAW, meaning it is a time interval based on processor counters (not subject to time adjustment via NTP) (https://stackoverflow.com/questions/14270300/what-is-the-difference-between-clock-monotonic-clock-monotonic-raw)
Current implementation on Windows uses QueryPerformanceFrequency/QueryPerformanceCounter, which is based on processor counters (not subject to time adjustment) (https://msdn.microsoft.com/en-us/library/windows/desktop/dn553408(v=vs.85).aspx)
Current implementation on MacOS uses host_get_clock_service(..., SYSTEM_CLOCK, ...), followed by clock_get_time(). I haven't yet found any good documentation on whether the SYSTEM_CLOCK is subject to slewing via NTP or not. For what it is worth, there is another way to do this using mach_absolute_time(), and that is what Python uses for its monotonic implementation (https://bugs.python.org/issue14104)

std::chrono:

On Linux/GCC, std::chrono::steady_clock uses clock_gettime(CLOCK_MONTONIC), so our current rcutils implementation differs from that (https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/src/c%2B%2B11/chrono.cc#L90) (clang does the same on Linux)
On Windows, std::chrono::steady_clock wraps the QueryPerformanceCounter API, so our current rcutils implementation mirrors that (https://msdn.microsoft.com/en-us/library/hh874790.aspx)
On MacOS/clang, std::chrono::steady_clock uses clock_gettime(CLOCK_UPTIME_RAW) if it is available (apparently since MacOS 10.12), and falls back to mach_absolute_time() if not (https://github.com/llvm-project/llvm-project-20170507/blob/master/libcxx/src/chrono.cpp#L132)

There is one other thing to consider, which is time spent during suspend. For instance, on Linux, CLOCK_MONOTONIC does not "tick" during suspend (https://stackoverflow.com/questions/6360210/androidlinux-uptime-using-clock-monotonic), but I believe on Windows, QueryPerformanceCounter does (https://stackoverflow.com/questions/24330496/how-do-i-create-monotonic-clock-on-windows-which-doesnt-tick-during-suspend). Again, MacOS documentation is lacking, so it is hard to tell, but it seems like mach_absolute_time() does not "tick" during suspend. (I just found this PEP, which lays all of this out nicely: https://www.python.org/dev/peps/pep-0418/#monotonic-clocks)

So, with all of the background above, it is worth looking into the expectations of the current users of rcutils_steady_time_now().

rcl_get_steady_time()
- Thin callback wrapper around rcutils_steady_time_now()
- As far as I can tell, never called in current implementation (excepting tests)
rcl_timer_*()
- Called by several functions in here
- Timer is wrapped:
  - rclcpp (TimerBase)
    - In turn, used to implemente GenericTimer and WallTimer
  - rclpy (WallTimer)
logging_macros.h.em
- In this case, the logging macros are looking to see if enough time has passed since the last print

So, given all the above, here are my conclusions/recommendations:

Using something like CLOCK_MONOTONIC (instead of CLOCK_MONOTONIC_RAW) is probably the correct thing. The reason for it is that local oscillators are not perfect, and do not always line up with the amount of time that has actually passed, and thus having a bit of an adjustment from the outside is probably a good thing.
Further, I think it behooves us to follow in the footsteps of std::chrono as @wjwwood points out, to keep expectations the same.
Thus, we should change the implementation on Linux to use CLOCK_MONOTONIC, and change the implementation on MacOS to use mach_absolute_time().

This is really long, so I'll quit there. Thoughts?

reconsider use of CLOCK_MONOTONIC_RAW #43

Description