Backward compatibility for timezone formats of UTC Date serialization

[arungitan]

Is your feature request related to a problem? Please describe.

This is related to https://github.com/FasterXML/jackson-databind/commit/07422d34c530f6d9ad3be14315bb2922da0754ff Since the default serialization of Date is changing timezone offset from "+00:00" to "Z" (in Jackson 3.0), would it be possible to have some options in 3.x to produce the old backward compat formats "+0000" and "+00:00"? We have some existing APIs which produce "+0000" and where (some) users are very sensitive to any change in the format. we were able to address this in 2.11 setting the provided colon flag to false. What would be the options to produce the same outputs in 3.x?

Describe the solution you'd like some flag (or other mechanism) that would allow default Date serialization to optionally produce the legacy "+0000" and "+00:00" timezone offset formats instead of the default "Z"

Usage example one possibility could be similar to the colon flag in 2.11. StdDateFormat::withLegacyTimeZoneForUTC(boolean useColon)

Additional context As mentioned above, this would help support backward compatibility of Date fields in existing api responses with minimal impact.

[cowtowncoder]

I think at this point I'd recommend custom serializer.

Although if anyone has time and itch, we now have DateTimeFeature which would work well for this use, I think.

[JooHyukKim]

Would DateTimeFeature a bit too official for "unwanted-but-only-there-for-backward-compatibility" feature?

Also, wondering if this should be, or good to be part of builderWithJackson2Defaults()? @cowtowncoder

[cowtowncoder]

I'd be fine with DateTimeFeature if support were added, since it'd be very easy way to expose it. But I don't think we have time to implement this for 3.0.0 GA; I plan to release it in next couple of days.

(if we were to add it, could discuss "builderWithJackson2Defaults()", but without impl no need to).