Which parsing bugs can we fix in a minor release?

[pitdicker]

To list a couple of issues:

• whitespace is allowed in too many places (overly relaxed whitespace parsing leads to unexpected parsing success (was Local.datetime_from_str errantly ignoring format whitespace) #660, Issue #660 whitespace exact #807)
• padding specifiers are completely ignored when parsing (no issue number yet)
  • example: 5:5:5 is accepted as a valid time by both %H:%M:%S, %k:%0M:%0S, while most would consider it invalid.
• %d and %e parse identical, same for %H and %k (Parsing explicitly space-padded format specifiers appears broken #1112)
• no way to require an offset to have a colon, %:z uses the same code as %z (Flexible offset parsing [2/3] #1083)
• no way to parse an offset with seconds, %::z uses the same code as %z (Flexible offset parsing [2/3] #1083)
• no way to parse an offset with only an hour, %:::z uses the same code as %z (Flexible offset parsing [2/3] #1083)
• no way to ignore padding in offsets (How to ignore zero padding for parsing the timezone offset? #1055)
• no way to parse Z as +00:00 offset (Parse Zulu suffix with %z? #945)
• accept minus sign (Issue 835 timezone offset allow MINUS SIGN (U+2212) (branch 0.4.x) #1087)

I consider most of these real bugs. Parsing doesn't work as documented and doesn't match formatting (so no guaranteed round-tripping).

In my opinion the issue with #1112, which let to a revert of a backport of #807, is that we became stricter about whitespace parsing without fixing the parsing of padding.

---

All changes here can be observable. It is pretty much guaranteed there are format strings in use that happened to work, but would fail when we start fixing these issues.
But I don't think it is better to batch up all these changes, and wait until a major release. (And not make new changes after that.)

[pitdicker]

An other change that I can imagine would be better as an opt-in, or something to wait with until a major release, is #1094:

• insert default values for some missing fields when parsing
• error on unused fields

If there are incompatibilities, it would not require users to alter the format string but to alter the types that receive the parsed value.

[djc]

There's a basic difference between "widening" changes that basically allow more format strings/input and "narrowing" changes that will generate errors of some kind for code that previously did something (hopefully useful). My usual approach would be that we should mostly stick to widening (allow minus sign, parse Z as offset).

For narrowing, I think there need to be very clear considerations in each PR about what the PR is breaking, an assessment how common that sort of usage might be (maybe backed up with data, by using GitHub code search or something?), and what the benefit is.

IMO it also makes a difference whether some change means we'll introduce new panic calls vs yielding an Err or None in some API that was already fallible.

But I don't think it is better to batch up all these changes, and wait until a major release. (And not make new changes after that.)

You don't think that is better? Consider that most downstream users will spend basically no effort verifying semver-compatible updates (other than running whatever tests they might have), whereas a semver-incompatible update requires that downstream users opt-in (as part of which they have a bigger chance of consuming release notes etc).

[pitdicker]

You write good replies in very little time...

For narrowing, I think there need to be very clear considerations in each PR about what the PR is breaking, an assessment how common that sort of usage might be (maybe backed up with data, by using GitHub code search or something?), and what the benefit is.

That seems like a good standard to me.

You don't think that is better? Consider that most downstream users will spend basically no effort verifying semver-compatible updates

Well, my thoughts are mixed about this is better to say. I agree with that. Yet making many changes to parsing without getting real-world testing for quite a while is also difficult?

[djc]

Well, my thoughts are mixed about this is better to say. I agree with that. Yet making many changes to parsing without getting real-world testing for quite a while is also difficult?

Yup, but we can respond quickly with bugfix releases to mitigate the impact.