Consider reverting #807 on the 0.5 branch

[pitdicker]

This issue is basically the opposite of #660.

My use cases for parsing with chrono have until now been to parse dates in whatever format they are given by users or encoded on websites. Mostly something close to natural language instead of a fixed RFC format.

I think there is real value in keeping the parsing code in chrono be forgiving by default. We already have strict parsers for RFC 2822 and RFC 3339 if users need those. And strictly speaking chrono cares about parsing, offering strict validation is one step further.

Since the beginning chrono has had special support for handling whitespace by treating it different from string literals. A whitespace character in the strftime format string would make the parser accepted any Unicode whitespace character (like space, non-breaking space, figure space, but also exoting things like tab and newline), and any number of such characters (0-∞).

#807 basically removed that support and makes our parser treat whitespace like string literals. It did not fully remove the now useless distinction between Item::Literal and Item::Space though.

• This will break many current uses of chrono that rely on the forgiving parser, for which we have no alternative solution they can migrate to.
• This will break the parsing of precomposed specifiers such as %r (12:34:60 AM) in which it is currently optional to have a space.
• This breaks code that currently relies on the parser being forgiving with space padding (see Properly support padding in parsers #1425 and Parsing explicitly space-padded format specifiers appears broken #1112).

Proposal for 0.5

• Revert this part of Issue #660 whitespace exact #807.
• Consider adding an Item::space_as_literal adapter like Item::to_owned for users that want to have strict parser. It would convert any Item::Space to Item::Literal, turning it into something that requires an exact match. This can even be done on the 0.4.x branch.
• Users that require a parser that acts as a validator can also manually write an array of Items, using Item::Literal instead of Item::Space. That is probably a good idea for performance anyway.

cc @jtmoon79

---

#1130 explored going a step further and making at least one character required when parsing Item::Space, and adding a chrono-specific specifier (% ) for an optional space. I proposed this as a compromise, but don't feel like pushing it and finding solutions for the breakage that would cause.

[djc]

I'm open to reviewing this.