When something doesn’t change for a long time we tend to get complacent and cut corners. For many years, the precision Mach clock in Macs has ticked away in nanoseconds, and we’ve come to assume that it always will. When it’s written to an entry in the unified log, because the machTimestamp has always been in nanoseconds, it’s easy to assume that it is and calculate time intervals accordingly.
Apple has warned us that its new Apple Silicon Macs won’t be the same, and continuing to make the assumption that Mach clock ticks occur once every nanosecond will prove seriously wrong. If any of your code uses mach_absolute_time, or anything derived from it, including the machTimestamp field in unified log extracts, now is the time to put your clock right.
As I have explained previously, Macs contain several different clocks and views of the time. Local reference clocks and timers which already work in proper time units such as seconds aren’t affected by this change. It’s hardware clock ticks, Mach precision time, which changes. On Intel processors, that tick has been one nanosecond long, so working out a time interval has been all too easy. Get the tick number (an unsigned 64-bit integer) at the first moment, get it at the second, take the first from the second and your answer is already in nanoseconds.
Read more at EclecticLight.co