`DateTimeSerializerBase` ignores configured date format when creating contextual

[brenuart]

DateTimeSerializerBase#createContextual creates a new serializer with StdDateFormat.DATE_FORMAT_STR_ISO8601 format instead of re-using the actual format that may have been specified on the configuration. See the following code:

final String pattern = format.hasPattern()
                                    ? format.getPattern()
                                    : StdDateFormat.DATE_FORMAT_STR_ISO8601;

Using the @JsonFormat annotation on a field will therefore reset the format to Jackson's default even if the annotation doesn't specify any custom format.

DateBasedDeserializer#createContextual behaves differently and tries to re-use the configured format:

DateFormat df = ctxt.getConfig().getDateFormat();
// one shortcut: with our custom format, can simplify handling a bit
if (df.getClass() == StdDateFormat.class) {
   ...
   StdDateFormat std = (StdDateFormat) df;
   std = std.withTimeZone(tz);
   ...
} else {
  // otherwise need to clone, re-set timezone:
  df = (DateFormat) df.clone();
  df.setTimeZone(tz);
}

Shouldn't the serializer follow the same approach ?

[cowtowncoder]

That sounds like a bug.

Would it be possible to create a stand-alone unit test to reproduce the problem? That would help verify the fix, and guard against future regression.

[cowtowncoder]

Yes, this definitely looks like a problem to me; code should not be by-passing contextual default.

[brenuart]

@cowtowncoder Maybe I should open another issue, but here is an interesting scenario...
Imagine I register a custom serialiser for java.util.Date (by means of a module for instance) instead of changing the date format itself on the mapper.

mapper.registerModule(
	new SimpleModule().addSerializer(
		new DateSerializer(
			Boolean.FALSE, 
			new SimpleDateFormat("yyyy/MM/dd'T'HH:mm:ss.SSSXXX"))));

Now suppose I annotate my pojo as follows:

public class Pojo {
   @JsonFormat(timezone="GMT+4")
   private Date date;
...

The annotation doesn't change the format but only the timezone - so I expect my custom format will be used. It won't be the case unfortunately: the handling of the annotation is such that it reverts to the format specified on the mapper itself and will bypass my custom module entirely.

See what I mean ?

[cowtowncoder]

Hmmh. To be honest, I did not design DateSerializer to be extensible/sub-classable, so its functioning (if any) is serendipitous... :-)

Now, I am not against trying to make it work (I don't see usage necessarily as wrong), but the better way, in my opinion, is to try to use "config overrides" functionality, added in 2.8, as it allows things like:

        mapper.configOverride(Date.class)
            .setFormat(JsonFormat.Value.forPattern("yyyy.dd.MM"));

and is designed to work with default handlers.

So... I don't mind your filing a separate issue for using DateSerializer if you wish.
But I would recommend using config overrides approach for actual usage, as it is better supported and likely more robust approach.

[brenuart]

I'll try the latter approach.
In short, you tell me a Module isn't necessary the best option to override the behaviour of types handled natively by Jackson - which is basically the case of my example.

How is you approach different from objectMapper.setDateFormat(new SimpleDateFormat(...)) ?