Yes, this is exactly what is happening. ParseExact processes its token 1
character at a time. To be able to realize that it should grab just "1"
instead of "10" when processing the "M" format, it would have to do an
extra sort of "matching pass" on the strings.

It would almost certainly not be possible to make this faster without
slowing other cases down. There would also be a slight compatability risk
if we change the rules for matching. We could add a new method or flag to
let you opt-in to this behavior. If we see this request a lot we will
consider doing it.

We are not very clear in our documentation about what will and won't work
here. In general:
1. All the custom formats of a particular culture should work through
ParseExact.
2. All formats should work if there are some sort of separators between the
tokens.
2. Fixed-with formats (e.g. "yyyy", "MM", "ss") should work even with no
separators providing you are using a gregorian calendar. Non gregorian
clandars may not work because they can have 2 or 3 digits years, which
throws the whole thing off.

Well track the feature request and see if we can improve our documentation
here. Thanks.

Anthony Moore
Base Class Libraries.

--------------------