issue 58 - NUMBER_INT should be specified when deserializing LocalDate as EpochDays

[kupci]

fix for issue #58 NUMBER_INT should be specified when deserializing LocalDate as EpochDays (unless lenient)

[kupci]

Needs a 'strict' test.

[cowtowncoder]

Looks good -- I'll add some comments on adding @since tags on new methods.

[cowtowncoder]

Quick question: this is against master: I assume this is because change might not make it in time for 2.10? If so that's fine; I'll create 2.11 branch right after 2.10.0 release, and probably want to rebase against that. I can of course try cherry-picking to backport, even if merged against master. But I assume we'd like this for 2.x series, if possible?

[kupci]

Cool, thanks for review. I'll make requested changes tonight. I have been going to upstream/master more out of habit, but I can certainly create PR against 2.10 if tonight CST is ok. One thing I need to figure out, to improve test, is how to send two config overrides, quick Google search and JavaDoc didn't reveal the technique, so I was thinking of creating a small test class and adding annotation there, which I've seen in other tests.

[cowtowncoder]

Ok, I think I did config overrides in a test yesterday. Method is different between 2.10 and 3.0, due to rewrite, but 2.10 does have builder-based approach now too I think.
I think change was in .... LocalDateDeserializerTest? Should be possible to chain.

Having said that, annotation is fine too of course.

[kupci]

I'll close this and create a PR for 2.10 instead. The annotation worked, for some reason the override was overriding the override, but I see it works for the property settings (just the .with(), so it's possible I need to call the 'with all config overrides' method or something like that.

[cowtowncoder]

As per my email comments, rebase for 2.10 branch is fine; just need to make sure that all existing constructors/methods in base class still exist in patch (deprecated).
And when merging forward (master / 3.0), remove such deprecated methods, only needed within 2.x.

[kupci]

@cowtowncoder Ok if I keep this one as-is, since it's ready, and then I will backport to 2.10?

[cowtowncoder]

Quick note: I just created 2.11 branch, as that will be needed here. It could have gone in 2.10.0, since minor versions can have some changes in behavior, but I try not to do such changes in patch versions. Problem being that there is small (but existing) chance of breakage.
I will try to keep 2.11 dev cycle much shorter than 2.10, 2.11 pre-release candidates maybe going out by December.

So, merge to master, cherry-pick to 2.11; or base off 2.11, either work.