ADDITIONAL SYSTEM INFORMATION :
Windows

A DESCRIPTION OF THE PROBLEM :
The current Javadoc for ZonedDateTime.toString() is misleading as it does not explicitly state that the string output follows the "shortest format" rule inherited from LocalDateTime and LocalTime.

While ZonedDateTime.toString() states it outputs a string "such as 2007-12-03T10:15:30+01:00[Europe/Paris]", it fails to mention that if the seconds and nanoseconds are zero, the seconds part is omitted entirely (e.g., 2007-12-03T10:15+01:00[Europe/Paris]).

This creates an inconsistency for developers coming from Instant.toString(), which always includes seconds. Developers relying on fixed-index parsing or specific ISO-8601 patterns face unexpected IndexOutOfBoundsException or parsing errors when a ZonedDateTime falls exactly on a minute mark.

Suggested Change:

Update the Javadoc of ZonedDateTime.toString() to align with the documentation found in LocalDateTime.toString() and LocalTime.toString() ( or OffsetDateTime.toString() ), clearly listing the possible ISO-8601 variations and mentioning that omitted parts are implied to be zero.

REGRESSION : Last worked in version 17

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
/**
 * Outputs this date-time as a {@code String}, such as
 * {@code 2007-12-03T10:15:30+01:00[Europe/Paris]}.
 * {@code 2007-12-03T10:18+01:00[Europe/Paris]}.
 * <p>
 * The format consists of the {@code LocalDateTime} followed by the {@code ZoneOffset}.
 * If the {@code ZoneId} is not the same as the offset, then the ID is output.
 * <p>
 * The output will be one of the following ISO-8601 formats:
 * <ul>
 * <li>{@code uuuu-MM-dd'T'HH:mmXXXXX'['VV']'}</li>
 * <li>{@code uuuu-MM-dd'T'HH:mm:ssXXXXX'['VV']'}</li>
 * <li>{@code uuuu-MM-dd'T'HH:mm:ss.SSSXXXXX'['VV']'}</li>
 * <li>{@code uuuu-MM-dd'T'HH:mm:ss.SSSSSSXXXXX'['VV']'}</li>
 * <li>{@code uuuu-MM-dd'T'HH:mm:ss.SSSSSSSSSXXXXX'['VV']'}</li>
 * </ul>
 * The format used will be the shortest that outputs the full value of
 * the time where the omitted parts are implied to be zero.
 * This matches the behavior of {@link LocalDateTime#toString()} for the
 * date-time portion.
 *
 * @return a string representation of this date-time, not null
 */