By international disagreement, last Sunday morning the UK, along with Europe, set its clocks back an hour from British Summer Time to good old GMT, and this coming Sunday it’s the turn of most of the US to do the same. Unless you’re in Hawaii or Arizona (excluding the Navajo Nation), which apparently don’t take part in this bizarre ritual. This is marginally better than ancient Greece, where adjacent cities kept separate and discoordinated calendars even though their sundials might have remained in sync.

While Macs should take this all in their stride, there’s one feature that twice every year throws its hands up in horror leaving you to work around it, the log show command. Whatever you’re doing in the small hours when the clocks go back or forward, don’t try accessing log entries written during those couple of hours or you could be sadly disappointed.

When clocks go forward in the Spring, log show just skips an hour, leaving a void in the fabric of time. But when they go back, a whole hour occurs twice, and wreaks havoc with the log. That’s another time feature subject to general disagreement, when to change to and from summer or daylight saving time. In the UK and Europe, that’s undertaken at 01:00 UTC (or, in the UK, GMT), while in the US it’s at 02:00 local time. It’s surely confusing enough that clocks change simultaneously across the whole of Europe, but to know when those in a US state are due to change you also have to know the local time before they change.

To see how bad this is, after the dust had settled on the system clocks of two of my Macs last Sunday, I dared to look with two log browsers, Ulbow that relies on the log show command, and LogUI that has better sense and calls the OSLog API direct.

Accessing the log using Ulbow, there was no problem around 02:00 or 01:00 GMT (if you must, UTC), when you might have expected the clock change to have had greatest impact. On both Macs running here at the time, it was exactly 01:49:02 GMT or BST that the log fell over. Calling for a single second of the log at that moment elicited over 300,000 entries on one Mac, and just short of four million on the other.

Whatever logoclysm strikes at that moment is over in the twinkling of an eye. Step back a second or two and you’ll see normal log entries reported in the previous time (here, BST +0100), and step forward to see everything orderly and in new time (GMT +0000). Use LogUI instead of Ulbow, though, and you can’t even tell when local time was adjusted, as that app expresses all times according to the prevailing setting at the time you read the log.

There is a seldom-used option for the log show command in -timezone local, which displays all times in the current local time. Yet the default is for log entries to be “displayed in the timezone at the time the entry was written to source archive or file”, as explained in man log. In some circumstances that may make entries more readable, but at least twice a year it causes chaos, and I’m puzzled why log show still makes that its default.

Although Apple doesn’t document it, I suspect that the Unified log, like other time-reliant subsystems in macOS, relies on Mach ticks since a clock datum. Because those are strictly monotonic, they can’t go backwards and cause the confusion seen here, unless of course you disable network time syncing and manually set your Mac’s clock to a time in the past (and even that is appearance rather than reversal). That used to occur on old Macs whose system clock relied on a small internal battery with a limited life. When that battery expired, the system date and time reverted to the datum of 1 January 1970, at the time the mark of a Mac that needed its battery replaced.

If you’re in the US, I wish you a smooth transition when your clocks go back this weekend, and hope you don’t need to access any entries in the log for the hour that time is out of joint.