Add `JavaTimeFeature.ALWAYS_ALLOW_STRINGIFIED_TIMESTAMPS` to allow parsing quoted numbers when using a custom DateTimeFormatter about jackson-modules-java8 HOT 6 CLOSED

On adding feature: PRs welcome.

from jackson-modules-java8.

Cheers! I'll try and rustle up something.

from jackson-modules-java8.

Hmmh. But what is the need to use "quoted numbers" instead of plain numbers?

from jackson-modules-java8.

Hmmh. But what is the need to use "quoted numbers" instead of plain numbers?

Unfortunately the data I'm reading is using timestamps formatted as quoted numbers. The systems producing this data are rather old and peculiar. And I would agree that in principle they need not be this way. But this is the reality I'm working with.

Nevertheless, without a formatter (i.e. @JsonFormat annotation) it is possible to read these dates in the current implementation. It is currently possible to de-serialize "3.141592653" into a ZoneDateTime. However when adding the @JsonFormat annotation this is no-longer the case. This is the inconsistency I'm trying to address.

Unfortunately I can not access the issue that prompted the original addition of the "read qouted numbers as timestamps" feature (datatype-jsr310#16) but looking at FasterXML/jackson-datatype-jsr310@f85c708 that resolved it appears to be a similar use-case.

So I am not looking to enable a novel use for quoted numbers, rather I'm looking to make an already supported use-case consistent with other features of the library.

from jackson-modules-java8.

Ok. That makes sense.

So, I am not against supporting such use cases; my main concern is with API. Unfortunately whereas there is now extensive configurability for "alternative Shapes" (accept String where Number is expected) is not quite what we have here, because Date/Time DOES accept String values (ISO-8610) but rather "String that is actually a Number. Because of that extra configurability is indeed needed.

But I am trying to limit use of DeserializationConfig for very specific/targeted uses: it should be for "bigger" features -- there are some legacy settings that are different, but for new things they should be general-purpose ones.

Given this, I think I would actually suggest adding configurability in JavaTimeModule; especially since this is not meant to affect JDK or Joda date/time types.

If this can be done, I'd be happy to get it merged.

I'll add similar note to jackson-databind issue.

from jackson-modules-java8.

Cheers. I'll have a look at how to accomplish this. Might take a little while.

from jackson-modules-java8.