Why should we fix inconsistency between platforms in this direction and not the other way?
Could it be that users would expect string representations produced by Java Time entities be parseable with Instant.parse?

After an internal discussion, we decided to keep this implementation similar to Java, which intentionally rejects Instant values without the seconds specified.

@dkhalanskyjb I'd love to see the reasoning behind this :) Could you share please?

Sure, here are several arguments for always requiring seconds:

• Not breaking consistency with Java without a good reason is already an argument in itself, and we didn't find a good reason.
• Symmetry with Instant.toString(), which always emits seconds.
• The conceptual model of Instant is that of a timezone-independent moment of time. When you're in a given time zone, even an implicit one, it makes sense to interpret 13:30 as 13:30:00.000000000, using common conventions. But an Instant can be interpreted in any time zone, including those with non-whole-minute offsets from UTC (like +01:23:45). If you receive a 2024-01-02T03:47+01:00, parse it as 2024-01-02T02:47:00Z, and then interpret it in the +01:23:45 offset, does it make sense that you have rounded the omitted seconds to zero, but now received a non-rounded wall-clock result back?

Counterarguments:

• Instant would be able to parse the output of OffsetDateTime.toString(). This should be easy to implement even if the default parse doesn't support it: [iOS] Fix parsing string without seconds #375 (comment)
• Instant would be able to parse the output of LocalDateTime.toString() if an offset is appended to it. But then, why not parse a LocalDateTime directly and then convert it to an Instant?

We decided to implement Instant.parse in a way that a sufficiently smart DCO would be able to strip away the parsing and formatting machinery if only default parse and toString were used thoughout. @ilya-g, what do you think about me doing this in a separate PR, so as not to block the release? AFAIK, this DCO doesn't even exist yet, so no one should be negatively affected by this PR.

what do you think about me doing this in a separate PR, so as not to block the release?

ok, let's leave a TODO