search

FasterXML / jackson-modules-java8

Set of support modules for Java 8 datatypes (Optionals, date/time) and features (parameter names)
Apache License 2.0
401 stars 117 forks source link

Test for strict localdate jsonformat #148 #149

Closed samwill closed 5 years ago

samwill commented 5 years ago

SMART which of course isn't supported here - or is it?

SMART is the default actually, which I think is still used even when lenient = true currently, so LENIENT is the one that's not supported. I think there should definitely be a new issue to discuss if that should change, currently the behavior is to silently change the day-of-month to the last valid one for the month given, as long as the day-of-month value given is 31 or less.

As for other types, now that I've gotten into it a bit, looks like this will probably impact anything extending the JSR310DateTimeDeserializerBase and has a concept of invalid values.

kupci commented 5 years ago

Merged! For the ResolverStyle settings (lenient/strict/smart), what I was thinking of was how to map the Oracle behavior to the Jackson settings (lenient/strict, and various ALLOW flags). @cowtowncoder perhaps a discussion for the Jackson developer list? Or maybe I'm over-analyzing things :)

cowtowncoder commented 5 years ago

Yes, this gets into that bigger question. My initial reaction is that SMART/LENIENT distinction is quite specific to Java 8 date/time, so it'd go as a further module section to sub-divide "lenient" (Jackson-concept). Whether default ought to be one or the other is more difficult question, but from compatibility perspective I would probably go with setting that is being used now... which sounds like it is SMART.

With 3.0 there is possibility that date/time might yet get merged with databind, which would complicate things. But as of now, it is still separate module unlike java8 datatype (Optional types) and parameter names which have been folded in.

As to best place to discuss this: mailing list might work, but maybe the best starting point actually would be to see JSTEP-5 outline on:

https://github.com/FasterXML/jackson-future-ideas/wiki/JSTEP

and create a document proposing desired behavior. This can be aimed at 3.0, or later 2.x, or (as is case with JSTEP-3, for example), some combination, progress towards 3.0 with some parts in 2.x.

JSTEP idea is quite new and still experimental, but I like the idea of light-weight documentation, planning, to share ideas that are "bigger" than single issue, but where participation via email/chat may be too transient.