Reading view

There are new articles available, click to refresh the page.

Last Week on My Mac: Seconds out

In 1657, one of the great scientists of the Dutch Golden Age, Christian Huygens, invented the pendulum clock, the first timekeeping device accurate enough to make a second hand worthwhile, as it typically only lost about 15 seconds per day. It was another century before John Harrison developed his marine chronometer, a clock sufficiently accurate to enable precise determinations of longitude. Another hundred years later, with the coming of railways across Europe, ordinary people started synchronising clocks so they caught their train, and our ancestors soon became the first slaves to time.

I’m beginning to wonder whether Apple intends reversing that history. Have you not noticed something odd about setting times in more recent Mac apps, how few allow you to set the seconds? You can see what has happened over the last few years in my log browsers, Ulbow and LogUI.

Most of Ulbow’s interface was written using AppKit seven years ago, and it uses a standard Date Picker with elements containing the year, month, day, hour, minute and second. Given that you can get more than 10,000 log entries in a second, I would have preferred to offer decimal seconds, but that isn’t possible within the standard AppKit picker.

LogUI was written from the start using Apple’s more recent substitute for AppKit, SwiftUI, eighteen months ago. That doesn’t use the AppKit Date Picker, but has its shiny new DatePicker instead. Components available in macOS are there limited to year, month, day, hour and minute. To be able to include seconds your code must be written for an Apple Watch, as macOS, iOS and iPadOS don’t allow seconds at all. That’s why you have to enter them in a separate TextField, although that could perhaps allow the use of decimal seconds.

When I wanted to obtain higher resolution timestamps for log entries in LogUI, I discovered that standard date formatting in macOS only resolves to milliseconds (10^-3 second), and couldn’t stretch to microseconds (10^-6 second), let alone the nanoseconds (10^-9 second) that can be obtained from Mach absolute time, as used internally in parts of macOS. Even that reference has recently become lower resolution, as each ‘tick’ in Apple silicon Macs occurs every 41.67 nanoseconds, rather than once every nanosecond as in Intel Macs.

There’s another difference between Ulbow and LogUI with regard to timestamps that you’re less likely to be aware of: Ulbow obtains its log records indirectly using the log show command, which can include the Mach absolute time of each entry. Instead, LogUI accesses those entries direct through the more recent OSLog API, which doesn’t currently expose such precise times.

Lest this appear too far removed from the world of the user, look in the menu bar clock’s settings, and you’ll see Display the time with seconds is an option, but not the default. When the clock is shown on the Lock Screen or screensaver, it only displays hours and minutes, never seconds, neither can any of the digital clock widgets supplied with macOS. While the Clock app does support decimal seconds, that’s only permitted in its Stopwatch where hundredths are displayed, as they are on an Apple Watch and other devices.

This becomes stranger still when you consider the methods used to synchronise internal clocks. Since High Sierra, macOS has used its own timed service, which Apple describes as “synchronizing the clock with reference clocks via technologies like NTP”, that’s the Internet service provided by time.apple.com as in Date & Time settings. When accessed over the Internet, it’s generally accepted that NTP should be accurate to within tens of milliseconds, although that can at times worsen to 100 milliseconds or more.

As far as I’m aware, no Mac has ever had a GPS receiver built into it, but every iPhone apart from the earliest, and those iPads with cellular support, include assisted GPS and GLONASS. Those are capable of providing time accurate to about 100 and 200 nanoseconds respectively. Even my 11-year-old car corrects its clock using GPS.

Although our Macs and devices can share almost everything else now, my Macs appear unable to adjust their clocks to the more accurate time that should be available to my iPhone. But as iOS is so shy about displaying seconds anywhere, it makes me wonder whether iPhones make full use of GPS time, or mostly rely on that obtained from the nearest cellular mast.

I’m curious whether this is a deliberate campaign to abolish seconds wherever possible, or just the result of doing what looks sufficient. Maybe I’m a mere slave to time, and the Time Lords in Apple Park are on a mission to cure me by travelling back four centuries.

How does an Apple silicon Mac tell the time?

Anyone familiar with Doctor Who will be aware of the power brought by control over time. Although there have been sporadic reports of problems with Apple silicon Macs keeping good time, and they may not synchronise sufficiently accurately for some purposes, they appear to have generally good control over time.

Last year I explained how macOS now uses the timed service with network time (NTP) to perform adjustments while running. This article looks at what happens before that, during startup, when the Mac has only its own devices to tell the time. Although the user sees little of this period, anyone accessing the log recorded during startup could find the timestamps of entries affected by adjustments. It may also provide insights into how Apple silicon Macs tell the time.

Methods

To investigate clock initialisation and adjustment during startup, I analysed approximately 100,000 consecutive log entries freshly recorded in the log of a Mac mini M4 Pro booting cold into macOS 26.2, following a period of about 14 hours shut down. These entries covered the period from the initial boot message for approximately 27 seconds, after I had logged in and the Desktop and Finder were displayed. This Mac is configured to Set time and date automatically from the default source of time.apple.com in Date & Time settings, and has both WiFi and Ethernet connections.

Multiple adjustments to wallclock time were recorded during that period, resulting in significant discontinuities in log timestamps. For example,
11:40:15.888717 void CoreAnalyticsHub::handleNagTimerExpiry(IOTimerEventSource *)::838:messageClients of 37 available events
11:40:10.045582 === system wallclock time adjusted
11:40:10.053309 000009.664065 Sandboxing init issue resolved: "Success"
11:40:10.053447 com.apple.sandbox.reporting Sandbox: wifiFirmwareLoader(49) deny(1) file-read-metadata /Library
11:40:10.112333 === system wallclock time adjusted
11:40:10.127559 com.apple.Installer-Progress Progress UI App Starting

In the first of those adjustments, the wallclock time was retarded by up to 5.84 seconds, and in the second it was advanced by at most 0.0589 seconds.

Because of those wallclock adjustments, times recorded in the log are discontinuous. Although it’s not possible to correct for the adjustments made completely accurately, assuming that each of those adjustments corresponds to standard time (such as UTC), those can be applied backwards through times recorded in the log to bring them closer to that standard. This could result in some brief periods of entries with times earlier than preceding entries, but is as accurate an estimate possible given the data.

Adjustments found

The narrative constructed from the log is summarised in the following table.

This starts with the initial record of the boot process, giving its UUID, within a second of the Power button being pressed (at approximately 0.0 seconds) to initiate the startup. That’s followed by a gap of just over 5 seconds before the second log entry.

The first two wallclock adjustments were made at 10 seconds, before there was any evidence of network connectivity. Those took place one second before the loginwindow was launched.

Two subsequent adjustments were made shortly after 24 seconds, immediately following the removal of the loginwindow after successful authentication. A further three adjustments followed in the 2.5 seconds after the user was logged in, while the Desktop and Finder were being prepared and displayed.

Log entries reporting the timed service was running didn’t occur until shortly before the last of those wallclock adjustments, and that was recorded in the log 0.0003 seconds before timed obtained its first external time.

Multiple internal clocks

A total of seven wallclock time adjustments were made before timed was able to obtain a time from any external reference. Over the first 10 seconds, before the initial wallclock adjustment, those were substantial, amounting to 5.8 seconds. For those changes to be made to wallclock time, there must be another source of time deemed more accurate, against which wallclock time can be compared and adjusted.

I’ve been unable to find any trustworthy information about internal clocks and timekeeping in Apple silicon Macs. It has been suggested (and Google AI is confident) that local reference time is obtained from the Secure Enclave. However, Apple’s only detailed account of features of the Secure Enclave fails to mention this. Initialisation of the Secure Enclave Processor also occurs relatively late during kernel boot, in this case at around the same time as the first two adjustments were made to wallclock time.

Conclusions

  • Apple silicon Macs may make multiple adjustments to wallclock time during startup, resulting in several discontinuities in log timestamps, which can cause discrepancies in event times.
  • Several of those can occur before the Mac has access to external time references, and timed is able to obtain an external time against which to adjust wallclock time.
  • Wallclock time can’t be the only local source of time, and appears to be adjusted against another local source.
  • Time isn’t as simple as it might appear.

睡了半年来第一顿好觉

我好久都没睡好了,值得记录一下。

从半年前手术开始,接连着出差、二次手术、年前的忙、过年的烦、年后的忙,一直到前几天的连续熬夜和通宵工作,我真的很长一段时间里都没有这么深的睡眠了。

前几天为了最后出方案,熬了两个通宵,公司内部的野心和追求都令我感到很失望,复杂的情绪交融在一起,非常难过。但最后还是用我的方式,引导大家选择了我想要的那个。尽管看上去我在力推另一个方案,但是人呐,对于自己没有概念的事情,靠嘴说是没有用的,对于他们来说,打出高中低来,选中间的,是他们能理解的方式。更好的那个,谈不上多超前,仅仅只是不值得而已。算了,以后总会有机会。

昨晚九点半,终于把所有设计文件、模型和工艺文件、USDZ 文件分别发送到了各个下一环节手中。接下来,不用我熬夜,轮到我监督他们干活交东西了。算是阶段性的胜利吧。

心情一好,我就看了半部《无间道3》。

前段时间跟筱烨一起看《无限超越班》,心里的戏瘾就痒痒,但是现在没有机会上舞台了,就上 Netflix 找了无间道三部曲开始看。之前分两周陆续看完了前两部,昨晚难得松懈一下,一口气看了半部三。

为了帮我补熬夜的气血,筱烨给我买了两次西洋参。第一盒前几天喝完了,前天又到了一盒,昨晚睡前温热地喝了一杯。

大概是工作的疲惫 + 阶段胜利的松懈 + 看电影的愉悦 + 西洋参补的气,一起让我睡了一顿好觉吧?

❌