-
Notifications
You must be signed in to change notification settings - Fork 519
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider reverting #807 on the 0.5 branch #1426
Comments
I'm open to reviewing this. |
This was referenced Feb 19, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
andItem::Space
though.%r
(12:34:60 AM) in which it is currently optional to have a space.Proposal for 0.5
Item::space_as_literal
adapter likeItem::to_owned
for users that want to have strict parser. It would convert anyItem::Space
toItem::Literal
, turning it into something that requires an exact match. This can even be done on the 0.4.x branch.Items
, usingItem::Literal
instead ofItem::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.The text was updated successfully, but these errors were encountered: