Xcode 15 | iOS 17 | Dateformatter issue with short style

Question

Created Jun ’23

Replies 3

Boosts 4

Views 3.1k

Participants 6

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

Answered by Scott in 756119022

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.

Boost

Answer 1

Scott OP

Jun ’23

Accepted Answer

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.

2

Answer 2

dan_morrow OP

Oct ’23

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.

2

Answer 3

Scott OP

Oct ’23

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.

1