Hello!
When using Date.formatted(_:) in Xcode 15 vs Xcode 14.3.1, we are getting back a different string. Please see the image below to see the difference in the string. Before "PM" the single space is a different length which I am not sure how that is even possible.
Any insight on this is helpful. Thank you!
I believe this is due to a new invisible character being inserted. If you copy paste the output into Pages you should see only one space.
What is the point of an invisible character in this case?
Also, I just looped through both different strings to check each individual character, and in Xcode 15.0 the asciiValue of the space before "PM" is nil. But in Xcode 14.3.1, the asciiValue of the space is 32.
It's using a different space character to the traditional ASCII one (code 32). Which is also why asciiValue doesn't work with it. There's actually a lot of different horizontal space characters in Unicode, each with their own purpose. See e.g. Wikipedia.
I'm guessing it's now using a Narrow No-break space (U+202F), both for aesthetics and to avoid the AM/PM dangling on a new line.
Yes what @wadetregaskis said. The new character for Xcode 15 is a narrow no-break space, so it doesn't have an ascii value since it's not an ascii character. You can check what the whitespace is with something like
let s = Date.now.formatted()
let whitespacesRange = s.ranges(of: { .whitespace })
for r in whitespacesRange {
print(s[r].unicodeScalars.map {
String($0.value, radix: 16)
})
}
This prints their unicode scalar value in hex
["20"] // the first whitespace, the standard white space
["202f"] // the second, NNBSP
Great information, thanks everyone!
By default, the output from a date formatter is intended to be read by a human. These values can and do change from release to release for all sorts of reasons (cultural, legal, aesthetic, and so on). If a change like this causes problems, it’s likely you need to rethink how you’re using the date formatter.
Why did this change cause you problems?
Share and Enjoy
Quinn “The Eskimo!” @ DTS @ Apple
For us, it caused some unit test failures because we had some complex formatting code that delegated to the formatting APIs under the hood. The change is fine, the unit test alerted us to the change, but I think its reasonable to test the output of formatting logic and verify that it renders what you expect.
I have a variation to this issue, where in I am able to see a narrow no space char on a few developer Macs and build systems. But there are a few build systems that executes the unit tests where we are seeing a normal space. We are having exactly same setup of tools and versions here, so wanted to understand if there is any conditional logic that drives this usage of NARROW NO-BREAK SPACE character in Date formatted string. Any help is appreciated.
Different locales, perhaps?