Comment 2 for bug 1898633

Ah, I see now what is happening. The userspace code is dealing with microseconds, while the syscalls all deal with nanoseconds.

So, when using absolute time, we read the clock (in nanoseconds), add that to our microseconds value after converting (that is, rounding the value), then set the timer, and read it back.

Take this run, for example:
[pid 27982] timer_create(CLOCK_MONOTONIC, NULL, [0]) = 0
[pid 27982] clock_gettime(CLOCK_MONOTONIC, {tv_sec=53718, tv_nsec=537178810}) = 0
[pid 27982] timer_settime(0, TIMER_ABSTIME, {it_interval={tv_sec=0, tv_nsec=0}, it_value={tv_sec=53718, tv_nsec=587179000}}, {it_interval={tv_sec=0, tv_nsec=0}, it_value={tv_sec=0, tv_nsec=0}}) = 0
[pid 27982] timer_gettime(0, {it_interval={tv_sec=0, tv_nsec=0}, it_value={tv_sec=0, tv_nsec=49842203}}) = 0

We read the time and set it 587179000 - 537178810 = 50000190 nanoseconds in the future, which is more than our 50000 microseconds. No surprise that, if you are fast enough, you are going to read a larger value back.

Not a kernel bug!
Cascardo.