{"id":32118,"date":"2021-04-14T15:30:30","date_gmt":"2021-04-14T19:30:30","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=32118"},"modified":"2021-04-14T15:33:20","modified_gmt":"2021-04-14T19:33:20","slug":"big-sur-has-changed-how-macos-formats-time","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2021\/04\/14\/big-sur-has-changed-how-macos-formats-time\/","title":{"rendered":"Big Sur Has Changed How macOS Formats Time"},"content":{"rendered":"

Howard Oakley<\/a>:<\/p>\n

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<\/p>\n

log command returned an error number 64<\/p><\/blockquote>\n

[…]<\/p>\n

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<\/code> now formats all its timestamp fields (field 0, timestamp) using a 12-hour clock and AM\/PM as appropriate.<\/p>\n

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.<\/p><\/blockquote>\n\n

Howard Oakley<\/a>:<\/p>\n

\n

Formatting like yyyy-MM-dd HH:mm:ss isn’t defined by Apple, but conforms to Report TR35 from the Unicode Consortium, and is exhaustively defined here<\/a>. That makes it clear that setting the hour using HH returns the hour in 24-hour format, ranging from 00 to 23.<\/p>\n

Yet when a Mac is set to use 12-hour format, that rule is broken: the hour is returned in h format rather than HH, as unpadded digits between 0 and 11, or maybe even 1 and 12. Furthermore, the am\/pm value is being added to the string.<\/p>\n

[…]<\/p>\n

Sure enough, adding the line\ndateFormatter.locale = Locale(identifier: \"en_US_POSIX\")<\/code>\nto my code restores respect for my formatting.<\/p>\n<\/blockquote>\n\n

Howard Oakley<\/a>:<\/p>\n

The advice given<\/a> is vague and raises more questions:<\/p>\n

“if you’re working with fixed-format dates, you should first set the locale of the date formatter to something appropriate for your fixed format. In most cases the best locale to choose is “en_US_POSIX”, a locale that’s specifically designed to yield US English results regardless of both user and system preferences.”<\/p>\n

How do we tell if our specific case is one of those “most cases”? What other effects might that setting have? If someone has set their Mac to run in Danish, should we be using something other than a US English setting here? But above all, why on earth would Apple change “in unexpected ways” a fixed<\/em><\/strong> format to something unspecified of its own invention which flies in the face of Report TR35? Just why is it impossible to follow the prescribed format string?<\/p><\/blockquote>\n\n

Previously:<\/p>\n