The same problem occurs for the following dates. (year doesn't matter)

'02/31/2014', '2016/02/31',
'02/30/2015', '2014/02/30',
'02/29/2015', '2015/02/29',

'31-02-2015', '2015-02-31', 
'30-02-2015', '2015-02-30',
'29-02-2015', '2015-02-29',

'11/31/2014', '2016/11/31', 
'31-11-2015', '2015-11-31'

This looks more like a documentation problem.  Actually,
strtotime() is very liberal in what it takes.  `2011-02-31` is
simply treated as `2011-03-03`.  Use checkdate() to check whether
a given date is valid.

I am rather tired of explaining this every other month. How about a note (warning?) that says something along the lines of how strtotime does not validate the input but instead tries to interpret it as a date in the most reasonable way possible. Month overflow is the most common issue by far; 2011-02-31 is not a valid date but the "most reasonable" interpretation of it is 3 days after 2011-02-28 which would be 2011-03-03. And other GNU/OSS date parsers act similarly. The other common issue is passing a timestamp and expecting to get that same value back (should have been "@timestamp") but strtotime reads it as some compound format without delimiters, like HHMMSSYYYY.

Assigning to myself to remind me to add a note explaining the behavior of strtotime

Just FYI, we already have a detailed note and explanation on the Date Formats [1] page about this behaviour.

[1] https://www.php.net/manual/en/datetime.formats.date.php