Can the real Slim Space Please stand up?

Today I ran into an interesting problem where some of our unit tests were failing locally, after upgrading to macOS Sonoma and Xcode 15.

Apparently there was a subtle change made to date formatting, and I was seeing this error.

An Xcode failure banner reading: XCTAssertEqual failed: (“11:30 AM”) is not equal to (“11:30 AM”) — the two strings look identical

11:30 AM is not equal to 11:30 AM

After lots of squinting, I pasted the error message into Sublime Text and spotted the error.

The same failure message pasted into BBEdit, which reveals the hidden <0x202f> narrow no-break space between the time and AM

Secret characters lurking in the mist

Fixing the test was straightforward, but it did leave me thinking I should probably write a comment to let future me (and others) know that I wasn't losing the plot.

Swift test code comparing a formatted date against the literal string “11:30 AM” on macOS 14 and earlier

You can’t see it, but I swear its there!

After chatting to Chris about this, he suggested escaping the Unicode sequence, which is undoubtedly a much better approach and makes it more obvious what is going on.

$The same test with the macOS 14 branch fixed to use “11:30\u{202f}AM”, spelling out the narrow no-break space$

Much better

So who is Mr. 202f? Apparently its a Narrow No-Break Space and is also used as a group separator, which given the context makes perfect sense.