The older AppKit API supports seconds in its Date Picker, but they’ve been dropped from its SwiftUI successor. There are many other signs our Macs are moving to less precise time. Is this intentional, to reverse our slavery to time?
time
Apple silicon Macs may not obtain an external reference time for many seconds after starting up. Do they adjust their local clock over that period, and if so, against what reference?
When the clocks went back, looking in the log for entries at 01:49:02 brought a very great surprise: in one Mac, nearly 4 million entries in a single second.
Apparently based on Mach absolute time, log entry times are converted to wallclock times. This exposes them to the vagaries of time zones, seasonal adjustments, and periodic wallclock adjustments. Here’s how all that works, and can confuse.
How to combine the time of interest with waypoints to reduce 100,000 log entries to just a handful, and discover what you’re looking for in the log.
Early Macs normally had their clocks synced manually, until System 8.5 introduced support for NTP. That later switched to a proprietary service, timed, in macOS 10.13 High Sierra.
This compares short time intervals obtained from log entry timestamps obtained from the log show command via Ulbow, those from LogUI using OSLog, and Mach Absolute Time.
Getting the date and time stamp of log entries to use rounded microseconds, and how to ensure a log extract uses the current time zone throughout.
It turns out that ‘nanosecond’ times introduced in LogUI are largely artefact. Is higher resolution timing really needed, and how can it be obtained?
How to ensure your Mac’s clock and time is as accurate as possible, what can cause problems, and how it works using the timed daemon, as revealed in the log.
The Eclectic Light Company 