Non-breaking spaces in date/time formats make parsing confusing

[jamesderlin]

This is motivated by https://stackoverflow.com/q/77457622/.

A recent-ish change to the Unicode CLDR made date/time formats use U+202F. That change breaks DateFormat.parse if used on strings that contain normal spaces. This change in behavior is not explicitly called out as a breaking change in the changelog for intl 0.18.0, and it is a bit surprising (and definitely confusing) when encountered in the wild.

Currently people wanting to accept either breaking or non-breaking spaces must use DateFormat.parseLoose. I propose that DateFormat.parse also should accept both. DateFormat.parseStrict can continue to make the distinction.

My rationale is:

• I expect that most existing users use parse instead of parseLoose, so changing the behavior of parse will unbreak them.
• parseLoose accepts other differences in format and quite possibly is too loose for some users who might want to reject some malformed strings instead of silently accepting them. In contrast, I think it's reasonable for parse to accept both breaking and non-breaking spaces since the distinction is invisible; I have a hard time imagining someone would consider '6:00 AM' malformed when '6:00\u{202F}AM' is expected.

At a very minimum, the distinction between breaking and non-breaking spaces should be mentioned in the DateFormat documentation. (Specifically, I'd mention something about it when describing the locale-dependent skeletons in the DateFormat class documentation and mention it in the documentation for DateFormat.parse/DateFormat.parseLoose/DateFormat.parseStrict.)

[jamesderlin]

After testing different versions of intl, this change in behavior seems to have been introduced in 0.18.1, which is even more surprising since that's a z-release and since the changelog entry for 0.18.1 doesn't mention anything about a CLDR update.

[mosuem]

This does show a need for more documentation around the intl package. I18n data is expected to change, so changes to that data are not breaking changes to this package. If a change in the data results in a break of a test or, even worse, production apps, this is a sign the code needs to be updated to not be dependent on i18n data.

One solution to this problem could be to remove the parsing functionality, as this is often the source of such errors. I suspect that in most cases, people are actually more interested in something like the parser from package:convert.