That's not competely true. ISO 8601 provides two formats, basic and extended. So both outputs are valid as long as the rest of the timestamp adheres to the same format. Since Jackson uses extended format exclusively, the current behavior is wrong.

@michael-o Ok. I think this was mentioned in an earlier discussion, but was not sure how to describe it. So, two questions:

1. Do you agree with the change itself, going forward? (I assume yes, just want to make 100% certain)
2. Could you suggest an improved wording to use here (feel free to edit if you can; if not let me know)

Also related, for overall change plans wrt Date/Time type handling:

https://github.com/FasterXML/jackson-future-ideas/wiki/JSTEP-5

where it'd be good to first group distinct ideas of improvements needed, in detail.

1. Yes, I do agree.
2. Do you refer to 4b51149? If yes, it definitvely needs improvement. Because Z has ben designed for RFC dates and not for ISO dates like telescoping X.

@michael-o Meant specifically wrt Javadoc for SerializationFeature.WRITE_DATES_AS_TIMESTAMPS primarily, and perhaps this issue title secondarily.

New title: Change default textual serialization of java.util.Date/Calendar for the timezone offset to comply with ISO 8601 extended format.

I will review the Javadoc of SerializationFeature.WRITE_DATES_AS_TIMESTAMPS.

See this part:

https://github.com/FasterXML/jackson-databind/blob/master/src/main/java/com/fasterxml/jackson/databind/util/StdDateFormat.java#L18-L22

This statement is problematic, even wrong. X cannot be used for RFC and ISO. The subtile difference is that is will always serialize Zulu with Z, never +0000 or 00:00.

I'd say that the Javadoc of WRITE_DATES_AS_TIMESTAMPS is acceptable. StdDateFormat needs imrovements for 3.0. It is a bit of a mess with respect to ISO 8601.

@michael-o I want to make sure I understand this part:

X cannot be used for RFC and ISO. The subtile difference is that is will always serialize Zulu with Z, never +0000 or 00:00.

As far as I can read JDK javadocs, X does produce Z for zero timezone offset; one that is legal (as well as alternate +00[:00]) for ISO-8601 as well. So I assume those are not problem parts.

So I assume you refer to the current (2.11) implementation of StdDateFormat, which does (for now) produce only numeric offset. This is easy to change, as comments already indicate (although claiming older specs being problematic, I'll change comment) that behavior was chosen for backwards compatibility.
Since changing that part (+00:00 -> Z) is yet another theoretically tiny, but in practice highly visible -- most likely causing tons of bogus test failures, but also breaking some amount of fragile code -- it seems best to only change colon inclusion for 2.11, and do +00:00 -> Z for 3.0 now. We can consider switch in 2.12 as well, depending on how 2.11 release goes.

Does above make sense?