Add READ_NUMERIC_STRING_AS_DATE_TIMESTAMP DeserializationFeature

[mpkorstanje]

To read numeric strings as date timestamp[1] a new feature toggle is needed.

1: FasterXML/jackson-modules-java8#263

This PR is paired with FasterXML/jackson-modules-java8#269.

[cowtowncoder]

Hmmh. Would this more generally work with timestamps for java.util.Date / java.util.Calendar too?

I guess I am trying to think of valid reasons to add (more) support for "quoted numbers" -- ideally those would not be used given JSON has native distinction between numbers and Strings.

[mpkorstanje]

I guess I am trying to think of valid reasons to add (more) support for "quoted numbers" -- ideally those would not be used given JSON has native distinction between numbers and Strings.

I'll answer here: FasterXML/jackson-modules-java8#263. Best to keep it all in one place.

[mpkorstanje]

Hmmh. Would this more generally work with timestamps for java.util.Date / java.util.Calendar too?

Currently as imagined, it would only work with the JSR310 classes Instant, OffsetDateTime, and ZonedDateTime. These all use the InstantDeserializer which parses quoted numbers leniently when a default date format is used.

[cowtowncoder]

Ok; I added longer description in FasterXML/jackson-modules-java8#263 but basically:

• Ideally DeserializationFeature entries are general-purpose ones and do not target specific limited datatype or module's operation.
• This feature is specifically targeted for Java 8 date/time, "Number as String" use case

So I'd rather get it added directly in that module as config option there, and avoid adding "too specific" DeserializationFeature. I realize that some of existing entries are non-optimal too; but the direction is to try to limit its use in this way.

[mpkorstanje]

So I'd rather get it added directly in that module as config option there, and avoid adding "too specific" DeserializationFeature. I realize that some of existing entries are non-optimal too; but the direction is to try to limit its use in this way.

That makes sense. I wasn't aware the module also had it's own options.

[cowtowncoder]

So I'd rather get it added directly in that module as config option there, and avoid adding "too specific" DeserializationFeature. I realize that some of existing entries are non-optimal too; but the direction is to try to limit its use in this way.

That makes sense. I wasn't aware the module also had it's own options.

Currently it is possible there aren't, but in general modules definite can have configuration options; some do, many don't (many use central configuration options to change their behavior).
Since there isn't XxxFeature settings you might want to go with an explicit boolean flag, with basic setter (with more options, Feature(s) and/or Builder make sense but an overkill at first)

[cowtowncoder]

Closing in favor of adding something like JavaTimeFeature for DateTimeModule