RFC3339: Reject parsing of non zero padded months

[marmeladema]

Hello and thank you for this useful crate :+1:

According to RFC3339 https://datatracker.ietf.org/doc/html/rfc3339#section-5 Months should be zero-padded to the left for up to 2 digits.

Current stable version 0.4.19 will nonetheless accept to parse non-zero-padded months like:

NaiveDate::parse_from_str("1998-1-20", "%F"): Ok(1998-01-20)

I understand changing this might be hazardous for backward compatibility reasons but I believe having strict specifiers to replace %m and %F would be useful to fully comply to RFC3339.

I found this while trying to load some test cases from JSON-Schema test suite repository. Especially this test states that non zero padded months should be rejected: https://github.com/json-schema-org/JSON-Schema-Test-Suite/blob/master/tests/draft7/optional/format/date.json#L156-L160

Thank you for taking the time to read me.

[SephVelut]

In real world cases, many people do not pad their months or days with zeroes. Parsing strings of dates, that often originate from user input or an api, requires flexibility. Compliance to a standard would be good, if the standard was actually a standard. It's only a standard on paper, with many use cases that I see in the real world bucking the standard.

[pitdicker]

parse_from_str is intentionally forgiving. You can use `DateTime<FixedOffset>::parse_from_rfc3339 to get a strict RFC 3339 parser.