Is there a possibility this stricter regexp could be a BC break? What would be the downside of keeping the previous regexp?

In theory, if someone doesn't use their browser but submits dates manually that could indeed feel like a BC break to them. But since#28372 this transformer isn't used anymore by any of the built-in form types. So yes, maybe we should relax this pattern here and inDateTimeToHtml5LocalDateTimeTransformer a bit. The question then is, how much relaxation should we do and when is a failure acceptable?

Just keeping the previous one?'/(\d{4})-(\d{2})-(\d{2})/'? (should be also applied toDateTimeToHtml5LocalDateTimeTransformer) - or at least put the added trailing patterns in a(?:...)? to make them optional?

I don't understand this. If we're implementing RFC 339, we can't discuss about the regexp, right? We should use the one defined in that RFC. Since we're fixing a bug, BC breaks are not considered. Strictly speaking, all bug fixes are BC breaks because we're changing the previous behaviour.

Javier has a valid point here. Let's just keep it the way it is.

I've not checked, but is usage like#28703 supposed to work? I mean, it worked before... by accident, right? Not saying we should not fix the BC break of course.

Using relative date formats was never supposed to work. It used to work accidentally like many invalid dates too. If we are really to make that supported, that will means that we have to abstain completely from detecting invalid input.

We were accepting any parseable date, with the format allowed by the date parser of PHP. That's a working validation strategy to me also.

The date parser accepts way too much input (see#28455 for such an example). I don't see how that is better.

I won't argue about how being stricter can be better (or not, e.g. for accessibility) - but this is still a regression.