StdDateFormat: add option to serialize timezone offset with a colon

[brenuart]

Jackson's StdDateFormat serializes datetimes without colon in the timezone offset, eg. 1970-01-01T01:00:00.123+0100.

Java8 and Joda have decided to include a colon in the offset, eg 1970-01-01T01:00:00.123+01:00.

Although Joda accepts to deserialize a datetime with or without the colon, Java8 considers the colon as mandatory and fails to deserialize datetimes produced Jackson's StdDateFormat.

In addition, some platforms like iOS also require a colon in the offset and are therefore also unable to read dates produces by Jackson's StdDateFormat.

Consequence: It would be nice if Jackson's StdDateFormat could be easily configured, extended or customized to include a colon in the timezone offset.

[cowtowncoder]

I agree in that it'd be good to improve inter-operability here.

Unfortunately this seems like a tricky thing to do. It is possible to specify format (via @JsonFormat(pattern=...), global defaults), which users probably have to do, but I can not think of other easy setting to use. Use of SerializationFeature would be a possibility although it'd seem unfortunate to add a datatype-specific feature in general set (it has been done often before, but seems wrong nonetheless). And then we have the practical problem that API should not be extended in patch release, which would suggest any feature added would have to wait until 3.0.
So, bit of a problem there.

[brenuart]

Maybe we could make StdDateFormat configurable via setter methods or constructor arguments.
This way users willing to change the default could simply do:

StdDateFormat fmt = new StdDateFormat();
fmt.setUseTzColumnFormat(true);
mapper.setDateFormat(fmt);

This way they have the full power of the StdDateFormat without having to subclass it and can customise its behaviour without requiring the introduction of new SerializationFeature.

[cowtowncoder]

That sounds like a good idea to me. For Jackson 3.0 we can get more creative -- I think (De)SerializationFeature's could use breaking up. And perhaps there's room for introducing other properties for for @JsonFormat as well.

(also: I think you mean "colon" for the character; I modified title)

[brenuart]

Nice. Let me prepare à PR for this.
And yes, you are right I meant "colon"... ;-)

[brenuart]

May be you should first review the other pending PR since they affect the same class. Otherwise we gonna have merge issues...

[cowtowncoder]

Ok, went ahead, change setters -> with-mutator. Will be in 2.9.1.

[caeaugusto]

Hello,

@cowtowncoder, just to confirm, there were no changes regarding the colon use on @jsonformat right? I couldn't get a working pattern that included it in the timezone.

I also didn't manage to get StdDateFormat to work with ZonedDateTime. My solution right now is a custom serializer that inserts the colon manually. Is there a better way to do it in 2.9.1?

Sorry for the noobish question, I'm new to the web world.

[cowtowncoder]

@caeaugusto StdDateFormat is only used for old JDK date/time types, java.util.Date and java.util.Calendar. It is not used for Java 8 date/time types, due to technical limitations, specifically since it relies on DateFormat type which is only used with older types.

Use of custom formats that include colon should, however, work with newer types, via @JsonFormat.pattern. If not, issue should be file on:

https://github.com/FasterXML/jackson-modules-java8/issues

So basically we have somewhat distinct handling of different date/time types: old JDK date/time, new (java 8) JDK date/time, and Joda.

[caeaugusto]

@cowtowncoder, thanks for the explanation. Originally I was using @jsonformat with the pattern "yyyy-MM-dd'T'HH:mm:ssZ" for a ZonedDateTime and that serialized the timezone with no colon. That was not a problem until I tested against Safari so I had to change it.

I understood that "yyyy-MM-dd'T'HH:mm:ssXXX" should serialize the timezone with the colon but the JSON produced has Z instead of the 4 numbers with the colon. I also understood that "yyyy-MM-dd'T'HH:mm:ssZZ" should serialize the timezone with the colon but that serializes it without the colon.

I honestly don't know if that's a bug and if it's jackson's, or if I'm using the wrong patterns. If it is indeed a bug, I'd be happy to file it.

PS: I do not use Joda at all.

[brenuart]

Have a look at FasterXML/jackson-modules-java8#38
It may give you some hints about what to do with your case...

[caeaugusto]

@brenuart thanks for helping, although I'm a bit confused because I don't have much knowledge on the topic. cowtowncoder mentions changing constructors to protected but they already are, and it seems to me that you would need them public so you wouldn't need MyInstantDeserializers class, right?

Even if this is right, I think that I should only need the JsonFormat annotation for my case.

[cowtowncoder]

@caeaugusto Reference issue seems to be about deserialization so it may not directly help, although it is about same challenge wrt colons (or no colons). Fundamental challenge has to do, I think, about Java 8 date formatting strings and options; Jackson module does not do any composition by itself (unlike latest version of StdDateFormat which does -- but only for the default pattern, and is not configurable in itself).

So I guess I would say that if JDK 8 date/time formatters can be configured to produce desired output, Jackson should allow such usage. If formatters are incapable of that for some reason it may be JDK issue. I think I have seen some allegations that latter might be true but I don't have first-hand experience or knowledge myself.

[caeaugusto]

@cowtowncoder it seems to me (not totally sure though) that the problem is indeed with the JDK. Thank you very much for taking your time to answer my questions!

[cowtowncoder]

@caeaugusto no problem; and I am sorry to hear in a way it is JDK issue... since it is not something we can easily address at this point. But if you or anyone else finds workarounds, links to documentation, maybe even reported bugs in oracle's bug tracker, those would be good additions here.

[lozforce]

spring.jackson.date-format=yyyy-MM-dd'T'HH:mm:ss.SSSXXX
The triple X means to use colon per SimpleDateFormat docs from Oracle.
https://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html?is-external=true