Inconsistency between default serialization of java.util.Date and OffsetDateTime

[KonstantinYegupov]

java.util.Date is serialized to epoch milliseconds by default; OffsetDateTime - to epoch seconds. That makes migration to Java 8 date classes exceedingly complicated.

[joschi]

@KonstantinYegupov I'm not sure what you're hinting at. Could you please elaborate on the problem you have?

[KonstantinYegupov]

Assume you have a data type with a "date" field. You want to serve instances of the type via REST API.

If you use legacy java.util.Date class for the "date" field, in the JSON generated by Dropwizard you will see the "date" field represented as a long integer with the value of "milliseconds since Unix epoch", e.g. 1444664056000. That's not very human-readable, but kind of acceptable. Epoch millis are pretty standard, many JS frontends are able to deal with that.

Assume someone told you java.util.Date is terrible and it's a good policy to never ever use it (which happens to be true). You listen and convert all the date types in your application to OffsetDateTime introduced in Java 8.

But now your "date" values are returned by in JSON as SECONDS since Unix epoch, e.g. 1444664056. This causes your frontend to interpret them as dates in early 1970. Sorrow and lamentation.

What's worse, it's not exactly obvious how to configure the date conversion.

The workaround I'm using at the moment is:

environment.getObjectMapper().setDateFormat(new SimpleDateFormat("yyyy-MM-dd'T'HH:mm'Z'"));

which probably should have been the default behavior.