Make `java.sql.Date` serializer default to same output as `java.util.Date`

[cowtowncoder]

(note: follow-up to #2403 )

Currently (in 2.x) java.sql.Date is serialized as String using value.toString(), which uses local timezone. This is different from other date/time types, but due to backwards compatibility issues, change can only be done in 3.0.

[michael-o]

Strongly support this to treat it as Instant.

[cowtowncoder]

One challenge is that handling itself will still be distinct (at least according to current plans) from JDK8 date/time. But the idea of making it work like Instant is of course what the goal would be.

At first tho it might be sort of as simple as making serializer extend same base class as that for java.util.Date, if that's not yet the case.

[michael-o]

Please also note that although java.sql.Date extends java.util.Date it applies a different format as defined by some SQL standard (a deviation of ISO 8601) and has only day or second precision.

[cowtowncoder]

@michael-o I was aware of different default representation (via toString()), but had forgotten about granularity limitations. Come to think of it, not even quite sure how it should work; inheritance here is wrong of course but not much we can do about it.

But just to make sure: is your suggestion to serialize it (when using String representation, not timestamp), as same ISO-8601 as what would be used for JSR-310 (java 8) date/time Instant?
(basically ignore possibly implied semantics of Date-only / Time-only)
That seems like reasonable approach (if not the only possibility), just want to make sure I did not misunderstand.

[michael-o]

But just to make sure: is your suggestion to serialize it (when using String representation, not timestamp), as same ISO-8601 as what would be used for JSR-310 (java 8) date/time Instant?

For java.util.Date and java.util.Calendar -- yes, use the counterparts from JSR 310.

(basically ignore possibly implied semantics of Date-only / Time-only)

Here is the exception, anything ìn java.sql.* must be treated separately because those formats are well defined and must not be changed by default -- along with the loss of precision.

[cowtowncoder]

Changed the definition a bit: change handling of java.sql.Date to be identical to java.util.Date (but overridable with format separately).

Also starting to think of whether to actually drop support of java.sql types from core databind in 3.0 -- a separate datatype module could be added for those who really want support for types. The benefit here would be removal of the whole of java.sql dependency form JPMS requirements (for Java 11 and beyond).

Will create a separate issue for that.

[michael-o]

I do support the separate module!