The short Dateformatter is now providing different space character. Binary value "11100010 10000000 10101111" rather than "00100000" for the space.
In documentation also have the "00100000" https://developer.apple.com/documentation/foundation/dateformatter/style/short
Binary value "11100010 10000000 10101111"
In hex those bytes are E2 80 AF, the UTF-8 encoding for Unicode U+202F NARROW NO-BREAK SPACE. So that’s a plausible character to use for putting space between words when formatting a string.
In documentation also have the [good old ASCII space character] “00100000”
If you mean the space in the example string “3:30 PM” then notice it’s labeled as an example, not as any sort of API you should rely on.
Dateformatter issue with short style
What is the issue? If you are trying to parse the formatted date string and expecting to find a specific character (e.g. an ASCII space between words) then you shouldn’t do that. That would be a form of undefined behavior, since the exact output of the date formatter isn’t documented, and in fact can be very different across languages and locales. In this case it sounds like they decided to improve the typography of formatted dates a little. If you just display the formatted string as-is then it should still work fine.
Scott , thanks for the explanation. Mainly we are facing issue with unit tests . there are multiple changes are done wrt Date
Having the same issue here, thought I was going crazy for a sec, getting test errors like "2:30 AM is not equal to 2:30 AM" (where one of them has a narrow space char).
Exact same problem here with unit tests. "12:00 PM ET" is not equal to "12:00 PM ET" ... in our case we are not using the ShortDateSyle but the dateFormat of "h:mm a v"
Binary value "11100010 10000000 10101111"
In hex those bytes are E2 80 AF, the UTF-8 encoding for Unicode U+202F NARROW NO-BREAK SPACE. So that’s a plausible character to use for putting space between words when formatting a string.
In documentation also have the [good old ASCII space character] “00100000”
If you mean the space in the example string “3:30 PM” then notice it’s labeled as an example, not as any sort of API you should rely on.
Dateformatter issue with short style
What is the issue? If you are trying to parse the formatted date string and expecting to find a specific character (e.g. an ASCII space between words) then you shouldn’t do that. That would be a form of undefined behavior, since the exact output of the date formatter isn’t documented, and in fact can be very different across languages and locales. In this case it sounds like they decided to improve the typography of formatted dates a little. If you just display the formatted string as-is then it should still work fine.
Scott , thanks for the explanation. Mainly we are facing issue with unit tests . there are multiple changes are done wrt Date
Having the same issue here, thought I was going crazy for a sec, getting test errors like "2:30 AM is not equal to 2:30 AM" (where one of them has a narrow space char).
Exact same problem here with unit tests. "12:00 PM ET" is not equal to "12:00 PM ET" ... in our case we are not using the ShortDateSyle but the dateFormat of "h:mm a v"
Gotta say, I greatly dislike the "don't do that" response. This has been a literal, old-school, x20 space character for decades. Why someone felt the need, now, to change the formatting... it seems rather arbitrary, and unnecessary. As was pointed out earlier, this is really just bothersome for unit tests. I have a number of tests which are checking output, and expecting only regular spaces in the output. Please help me understand why this change needed to happen.
Please help me understand why this change needed to happen.
Because a hippie dropout named Steve Jobs audited a calligraphy class at Reed College in 1972. Seriously... sort of. That’s often cited as the genesis of Apple’s exacting quality of typography over the years.
In this case, I’d argue that using a no-break space is a nice little improvement, so that (for example) 9:41 AM won’t get split across two lines if it falls at the end of a line in a formatted paragraph. Otherwise with a normal space, this could get split at a line break, which looks a little odd.
