LocalDateDeserializer accept "numeric String" (like, "7"), should not

[esHack]

Following dateofbirth(LocalDate) is a valid request(by jackson) even its an integer. It just add days to 1970-01-01 which is 1970-01-07.
Not every one need this to be valid. Its important to have flag in the @DateTimeFormat to disable this

{
"email": "[email protected]",
"dateOfBirth":"7"
}

More details available here

[cowtowncoder]

Not quite sure if a flag is needed, but I agree in that it seems strange that a STRING value like this would be accepted -- it does not conform to any ISO-8601 format I think.
And just because it looks like a quoted integer does not -- I think -- mean it should be treated as such.

So I think it should rather fail with format mismatch.

[cowtowncoder]

Thinking about this, I think I will want to tackle this via "leniency" setting, introduced by @JsonFormat annotation for fields (in 2.0) and for types using "config overrides" mechanism (2.8). Long story short I think that when

1. Lenient handling enabled (default due to backwards compatibility), numeric timestamp is allowed
2. If lenient disabled, numeric timestamp NOT allowed.

But I think that number-as-String should not be allowed either way; I consider this issue to cover that specific case.

[cowtowncoder]

@esHack I don't think your example is correct: I don't LocalDateDeserializer accepts value "7", although it does accept integer/number value '7'.

But for preventing use of integer there's now #129 specifically; so closing this one in favor of that (given that integer-as-String does not work).

[cowtowncoder]

Implemented via #129, will add usage notes there.