dmesg -T and the actual time a message was produced, noted on
current-users by Geoff Wing (Oct 27, 2018).
The size of the offset would depend upon architecture, and processor,
but was the delay from starting the clocks to initialising the time
of day (after mounting root, in case that is needed).
Change the kernel to set boottime to be the time at which the
clocks were started, rather than the time at which it is init'd
(by subtracting the interval between).
Correct dmesg to properly compute the ToD based upon the
boottime (which is a timespec, not a timeval, and has been
since Jan 2009) and the time logged in the message.
Note that this can (rarely) be 1 second earlier than date reports.
This occurs when the time when the message was logged was actually
in the next second, but the timecounters have not yet processed
the tick, and so the time of the last tick, near the end of the
previous second, is reported instead. Since times are always
truncated, rather than rounded, it is occasionally possible to
observe that disparity (if you try hard enough).
IOW: sys/kern/subr_prf.c:addtstamp() uses getnanouptime() rather
than nanouptime().
Note in dmesg(8) that -T conversions are gibberish other than
when the message comes from current the running kernel. (It
could be fixed when -M is used, for messages generated by the
kernel whose corpse is being observed. But hasn't been...)
7008793d77