Twice each year we go through the ritual of changing our clocks, and our Macs and devices suddenly add an extra hour or remove one. With major releases of macOS occurring annually, you may never get to see the same behaviour twice. Last weekend in the UK we put our clocks forward to Summer Time, a procedure which had already been performed across North America a fortnight earlier. So what happens when your Mac does this?

Setting times

Software which lets you set the time using a standard date picker should behave unusually around the time of the clock change.

By convention, in the UK and Europe changes to and from Summer or Daylight Saving Time are made at 01:00:00, although in North America it’s normal to do that at 02:00:00 local time. In apps like my log browser Ulbow, changing the hour skips straight from old to new time: increase the hour from 00:00:00 and the control jumps ahead to 02:00:00. This is because the time set there is in the current time zone, now +0100, even when it refers to times before the clock change, if they’re on the day that the clock change takes place. Change the date to an earlier or later day, and the date picker works entirely in the time zone applicable to that day.

As the UK changed its clocks on 28 March, all times set for that day are considered to be in Summer Time, +0100. Those for the previous day remain in +0000, though. When your location is in North America, those behaviours should apply to 14 March instead.

Datestamps

In log extracts and other places where macOS writes datestamps, subject to any option to express time in a single unified format, datestamps are written in the time zone set in the Mac or device at the time they were collected. For example, consecutive entries in the unified log might read:
2021-03-28 01:12:31.878320+0000
2021-03-28 01:12:31.878325+0000
2021-03-28 02:12:32.443563+0100 === system wallclock time adjusted
2021-03-28 02:12:32.530253+0100
2021-03-28 02:12:32.530258+0100

Note that macOS doesn’t perform the clock change at the standard time, but that occurs some time afterwards, here with a delay of over 12 minutes. If you’re ever unsure whether those log entries are truly consecutive, or have merely lost an hour, examine the Mach ticks field in the log, as that should show no such discontinuity.

Why was the change so late?

Although the datestamps written to the log didn’t change until over 12 minutes after the standard moment for the clock change to take place, other times in that Mac were corrected more promptly. In a log entry made at 00:59:59.997317+0000, for example, the entry refers to the time as being 02:00:00 British Summer Time.

Last year I reported how the Mac’s timed service accessed the NTP server to initiate a check which then led to the system wallclock time adjustment. This year, running Big Sur 11.2.3, there was no such activity apparent. Instead, something of a row developed over access to the user’s .GlobalPreferences.plist preference settings at 01:00:00.334675+0000. ContainerMetadataExtractor wanted to read that key list of global settings, but this was repeatedly denied on the basis that it was outside the sandbox. Those attempts were finally abandoned at 01:00:00.699089+0000, and there was no sign of timed checking the NTP server or attempting any earlier correction to the clocks.

It therefore looks likely that macOS blocked more prompt attempts to correct the system wallclock time. Imagine having code which only runs once a year, then come the day of the race it gets blocked by a sandbox error.

It still surprises me that macOS is slower to fully register these clock changes than I am going around the house manually changing our clocks. I’ll revisit the issue of clocks changing when they next attempt the more troublesome task of falling back an hour in the autumn.