No validation on date parsing

[epage]

With #187, we dropped most of our date validation, like 2021-02-31 now works.

Looks like chrono has some pretty complex lookup logic to prevent that

Playground of it erroring

[epage]

Options

• Revert the change
• Add a feature flag for full date validation, which pulls in chrono
• Do nothing (like toml-rs)

[ordian]

Curious how other parsers handle that (e.g. in other languages). It seems toml spec specifies the date should follow the https://datatracker.ietf.org/doc/html/rfc3339. And if chrono panics on construction instead of returning an error, that's not good either, but I would lean towards Do nothing and documenting this behavior.

[epage]

Chrono offers panicing and Option variants of its constructors

Looking at the RFC, it seems like it shouldn't be too bad to address days of month. I assume the complexity in chrono is coming from other functionality.

Leap seconds is an interesting one. If you don't bother with a lookup table, it simplifies things but knowing whether you can have a leap second or not is dependent on the month. So a date-less time can't do validation and combining a date and time can error.

[epage]

As for other languages, toml-test validates that toml parsers reject months with 50 days but doesn't validate further. So parsers using that test (like go) at least validate that much.

Python's toml loads into datetime which handles leap years. I did not verify how it handles leap seconds

[parasyte]

If my preference is at all useful here, I would like chrono behind a feature flag if you intend to add it again.

The project where I use toml_edit already has a ton of dependencies. And while chonro is not large compared to everything else I depend on, I do try to keep the tree as thin as possible by removing unnecessary features. A feature flag would just be really nice to have.