We could put it in the message, but that's *slightly* fiddly - it would be 
simpler to add a separate property...

This issue was closed by revision 6c55ba422471.

I'm hoping it's fixed, anyway :)

Here are a couple of samples. Basically there are two situations - ones where 
we fail part-way through the parse, and ones where we only fail afterwards, at 
the point where we try to use the values.

Code: LocalDateTimePattern.ExtendedIsoPattern.Parse("1959-XX-12T00:00:00").Value

Unhandled Exception: NodaTime.Text.UnparsableValueException: The value string 
does not match the required number from the format string "MM". Value being 
parsed: '1959-^XX-12T00:00:00'. (^ indicates error position.)


Code: LocalDateTimePattern.ExtendedIsoPattern.Parse("1959-15-12T00:00:00").Value

Unhandled Exception: NodaTime.Text.UnparsableValueException: The month 15 is 
out of range in year 1959. Value being parsed: '1959-15-12T00:00:00'.

Now you could definitely argue that we should bork at 15, and indicate that as 
the error position. However:

- That (in theory) requires knowing which calendar system we're parsing
- ... and that might be specified *after* the month

Options:
- Live with it... at least we're providing the value now!
- Understand the maximum value for months (and days of month) over *all* 
calendar systems
- Remember the position of different values, so we can retrospectively fail 
with the right position
- Use the fact that we know whether or not the pattern has a calendar specifier 
to use a calendar-specific "max month" value early if we know that it's not 
going to change

I'm fine to live with it for the moment, but the last option might make a 
certain amount of sense.