`DurationSerializer` ignores format pattern if nano-second serialization enabled

https://github.com/FasterXML/jackson-modules-java8/blob/3075bfe40669fd1853407c2f949a63d1f1f1fa8b/datetime/src/main/java/com/fasterxml/jackson/datatype/jsr310/ser/DurationSerializer.java#L84-L88

If I do this, I expect an integer number in JSON representing the number minutes:

@JsonFormat(pattern = "MINUTES")
@JsonProperty("durationInMins")
Duration duration;

But it serializes it as nanoseconds. After some debugging, I decided to add , shape = NUMBER_INT in order to force com.fasterxml.jackson.datatype.jsr310.ser.JSR310FormattedSerializerBase#useNanoseconds respond false, but it has no effect because shape is not used in the factory method I linked above.

Found a workaround: adding , without = JsonFormat.Feature.WRITE_DATE_TIMESTAMPS_AS_NANOSECONDS to @JsonFormat. However, it only works if I add it to each property, adding it on class level has no effect.

[cowtowncoder]

@Sam-Kruglov FINALLY found time to get back to this and hope I fixed it correctly – trivially simple change but I’m slightly worried about regression. Still, as things are tests pass and it’ll go in 2.14.0 unless something is found.

But I was wondering wrt Instant you mentioned has similar issues: would it be possible to show similar unit test? If so, could you please file a separate new issue for type(s) and I should be able to see if I could do more fixes before 2.14.0 release (planning to start release candidates soon).

[cowtowncoder]

I added a modified, failing test to reproduce the issue. Unfortunately I don’t have time to pursue this further at this point, but I hope someone else can – I will make time to review PRs and so on, just not actively write a patch myself.

@kupci Not sure what you think – might be able to add in a 2.13.x patch although I am also worried that a change might be needed in construction/contextualization.