If someone wants to provide feedback as to which of the following is preferable to fix this problem, I would be happy to make a pull request to fix it:
1) We should simply provide an appropriate error message.
or
2) We should implement some sort of lookahead to actually handle this type of format.
or
3) Something else?

It looks like the date string is taken to be (in Y-m-d format for presentation) 0989-30-71, which when wrapped around into a “normal” date gives the mentioned 0991-08-10. 

The string is broken up as follows:
“n” wants a two-digit month number, it accepts “30”.
“d” wants a two-digit day of month number, it accepts “71”.
“Y” wants a four-digit year number, it accepts “989”.

The warning is generated when “30” and “71” are checked for being “valid" month and day of month numbers, respectively.

Internally, in many cases, there is no difference between using the leading-zero format character and the non-leading zero one. E.g. “n” and “m” are extracted using the same internal code. These are described in the documentation already.

Your claim that this date format is not supported is incorrect. It is supported; it simply doesn’t behave as you were expecting. Should format characters like “n” and “m” give different outcomes for this function? Perhaps, but that’s opening the time string parsing up to a not insignificant re-write. Should the string parsing try to be a little more “clever” by attempting to get a “valid” date from the multiple possible combinations in ambiguous date strings? Perhaps, but do we want to introduce this complexity (and we’ll never get it right 100% of the time)?  I don’t have an answer.

In your particular case, I can only suggest manipulating the date string such that it is no longer ambiguous; perhaps by adding appropriate delimiter characters between the different date parts.

@ salathe@php.net:
I have to strongly disagree with you here.

1) The documentation (http://us3.php.net/manual/en/datetime.createfromformat.php) is vague about "n" expecting a month with no leading zero, but it implies that "m" is for a month with a leading zero and that "n" is for a month without a leading zero. Furthermore, for the date() method, the documentation clearly states that "n" is "Numeric representation of a month, without leading zeros". It seems pretty clear to me that it ought to be exactly that in all cases, regardless of how it currently works internally. Otherwise, we should adjust the documentation to reflect that "n" and "m" both represent a month with a leading zero. I think you'd agree that would be a bad idea given how they are used elsewhere (i.e., for formatting dates as strings with date())

2) To be clear, I'm not saying the format isn't supported. Clearly it is or I would have received a more severe error message. The point is that it is not supported *correctly*. Consider this example:
$dt = new DateTime( '2013-12-01' );
$date = date_create_from_format( '!ndY', $dt->format('ndY') );
assert( $dt == $date ); // passes
$dt = new DateTime( '1989-03-07' );
$date = date_create_from_format( '!ndY', $dt->format('ndY') );
assert( $dt == $date ); // FAILS

Are you going to tell me that is an acceptable outcome?
You said it simply doesn't behave as I expected, but one would only expect it to be broken like this if they had read the underlying implementation (like I did) and found that it only works from left to right. The documentation does not mention this little tidbit.

3) I understand that it would require significant effort to alter the algorithm to take these types of cases into account. That's why I suggested that another alternative would be to store an error indicating that the format doesn't work properly, so that at if it's not going to work the way one would expect we would at least get feedback about that.

4) It was rather elementary to solve this issue (basically in the way you described) when we encountered it some months ago. I am just trying to fix this so that the next person doesn't run into this and have the same confusion that my team encountered. Our code used a dynamically entered php date format, so it required a hacked workaround to support this specific case when it should have just worked.

5) Why would you ever indicate that we might never get something right? Shouldn't we be striving for bug-free code here? Especially when someone from the community has already offered to do the work-- whatever that work may be. Granted, it is difficult to get complicated code to act in a sane manner 100% of the time, but that is no excuse for not trying to do so.

6) My frustration here is not that the problem exists. Bugs happen. People fix them. My frustration is that someone with an @php.net email address would think this is a non-issue.

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

If you pass in an ambiguous string for a format, there is nothing we can do. Is 1112013 supposed to be 1-NOV-2013 or 11-JAN-2013 with a format of "!jnY"? 
Chances are that you can't tell us either. Or what about 1092013 with "!jnY" - that could also be both 1-SEP-2013 or 10-SEP-2013?

We *could* make n non-greedy, and m greedy, but that still does not solve the 1112013 case—it would just pick 1-NOV-2013 - even if you meant 11-JAN-2013.

Passing in an ambiguous string is not something that we can ever support for 100% - it only works properly if you add delimiters.