A number of those using my free utilities Ulbow, Mints and T2M2, and possibly others, have recently noticed a bug which prevents them from obtaining any log extracts. When you try to get a log extract or, in T2M2, to run a check on Time Machine, you are shown an error dialog reporting that
log command returned an error number 64
This appears to have started from macOS 11.2.2 or thereabouts, and doesn’t affect Consolation, though.

The reason for this occurring is that, contrary to the scant documentation which Apple provides, when the system clock is set to display time using a 12-hour clock rather than 24-hours, log show now formats all its timestamp fields (field 0, timestamp) using a 12-hour clock and AM/PM as appropriate.

I have no earthly idea what possessed Apple to make this change, nor why it hasn’t made this clear in its release notes. However, if you parse or analyse log entry timestamps, it breaks that completely. Quite why anyone would want to see all the timestamps in the log in such a non-standard and inappropriate format I have no idea. Maybe it was just a terrible accident.

Thankfully, there’s a simple workaround: set your system clock to use 24-hour Time in the General tab of the Language & Region pane.

Unfortunately, changing the code in these apps to accommodate 12-hour clocks and every other possible variant would require that each log entry had its timestamp field parsed painfully to convert it to a standard format. That in turn imposes a significant overhead when obtaining and processing every log extract. I have absolutely no intention of imposing that on every user of those utilities. So all I can recommend is that you switch to a 24-hour clock until such time as Apple fixes this aberrant behaviour.

The log is not the right place to introduce such needless complications, and should format timestamps in a uniform way regardless of user interface settings.