BUG: Format mismatch doesn't coerce to NaT
- [x] closes #24763 
- [x] tests added / passed
- [x] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [x] whatsnew entry

lgtm. @jbrockmendel any issues? Hmm I worry a bit about users typoing the format string, and ending up with all NaT values. But, I don't suppose there's a way to say that `H%:M%:S%` is necessarily an invalid format string, since we don't require that the year, month, or day be specified... I wonder, are there two cases? Something like

```
format="Y%:%M:%D
```

the user probably has a typo in the year formatter, but it's hard to say. With something like

```python
format="Y%:H%:M%
```

it's (AFAIK) impossible for that to ever parse anything, since there's no valid format substring. Could we raise or warn in that case? @TomAugspurger Yeah, always raise format parse error is another option.

Maybe should `OutOfBounds` respect `errors` kw, but `ValueError`  (format parse error) shouldn't (always raise)? > Maybe should OutOfBounds respect errors kw, but ValueError (format parse error) shouldn't (always raise)?

I haven't looked, but that seems reasonable to me. I don't think we *need* to differentiate a bad parse error when ``errors='coerce'``, we don't have a mode to handle this. Maybe can address in a future PR, but this lgtm. @TomAugspurger ? If possible, I'd prefer that an invalid format string raises immediately.
But I'm not really sure if that's possible, and won't have time to look.
This is probably an improvement for the original issue.

On Mon, Jan 21, 2019 at 7:18 AM Jeff Reback <notifications@github.com>
wrote:

> I don't think we *need* to differentiate a bad parse error when
> errors='coerce', we don't have a mode to handle this. Maybe can address
> in a future PR, but this lgtm. @TomAugspurger
> <https://github.com/TomAugspurger> ?
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/pandas-dev/pandas/pull/24815#issuecomment-456071162>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABQHIkcZFrZQ3bssufugj-jijNO8a9P2ks5vFb4wgaJpZM4aFC0i>
> .
>
 actually I think this conforms to our errors keyword. 