Why can’t Java 8 DateTimeFormatter.ISO_DATE_TIME handle offset zone without colon in it, ISO standards have 4 Offset formats.?

Question

DateTimeFormatter formatter = new DateTimeFormatterBuilder()
    // date/time
    .append(DateTimeFormatter.ISO_DATE_TIME)
    .toFormatter();

//can't handle the first example

System.out.println(OffsetDateTime.parse("2022-03-17T23:00:00.000+0000", formatter));
System.out.println(OffsetDateTime.parse("2022-03-17T23:00:00.000+00", formatter));
System.out.println(OffsetDateTime.parse("2022-03-17T23:00:00.000+00:00", formatter));
System.out.println(OffsetDateTime.parse("2022-03-17T23:00:00.000Z", formatter));

Solution / work around is in Java 8 Date and Time: parse ISO 8601 string without colon in offset

I am checking why Java 8 ISO_DATE_TIME can't handle the format which is an ISO Complaint - https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators

<time>Z
<time>±hh:mm
<time>±hhmm
<time>±hh

My question is simple and straightforward -> Why is Java 8 not handling formats mentioned as part of ISO Standard ( only 4 ISO offset formats )?

https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html#ISO_DATE_TIME

https://docs.oracle.com/javase/8/docs/api/java/time/ZoneOffset.html#getId--

Your observation is correct. Have you got a question? What is it? In the ISO 8601 standard the colon is optional. java.time including `ISO_DATE_TIME` parses *the most common* ISO 8601 variants, not all of them. The inability to parse the offset without the colon is probably the best known example of an ISO 8601 variant that is not parsed natively. If you need to parse it, you can build your own formatter as also shown under the question that you are linking to. — Ole V.V., Apr 25 '23 at 09:32
As per the official documentation -> There no mention of what you are claiming. https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html#ISO_DATE_TIME. — Mohamed Afzal, Apr 25 '23 at 09:41
"As per the official documentation -> There no mention of what you are claiming." follow the link for "offset ID" (3rd bullet). It says "There are 3 formats", one of which is simply Z, the other two require a colon. — Andy Turner, Apr 25 '23 at 10:01
@AndyTurner : yes Thanks for mentioning, in doc list the formats thats handled https://docs.oracle.com/javase/8/docs/api/java/time/ZoneOffset.html#getId-- The ID is minor variation to the standard ISO-8601 formatted string for the offset. There are three formats: Z - for UTC (ISO-8601) +hh:mm or -hh:mm - if the seconds are zero (ISO-8601) +hh:mm:ss or -hh:mm:ss - if the seconds are non-zero (not ISO-8601) — Mohamed Afzal, Apr 25 '23 at 11:11
Thanks for the question. I have pasted it into the question for you. More depth and clarity to your question is always welcome and should always be given as edits to your original question. You may then at-sign ping me (or who asked) in a comment if you find it appropriate to notify of the edit. — Ole V.V., Apr 25 '23 at 11:19
For why it doesn’t: We’d either have to enter into a guessing game or ask the original developers, Stephen Colebourne in particular. My interpretation is what I have already said: they deliberately chose to support the most common ISO variants and not all of them. Supporting all possible ISO 8601 formats would have been a **major** extension to java.time, so quite clearly not what they would want. And then they had to draw the line somewhere. In the big picture I personally find that leaving out the variant without colon in the offset seems fair. — Ole V.V., Apr 25 '23 at 11:25
And to be honest, with the update your question was closed with the wrong reason, it is no more missing clarity, but should probably instead have been closed as opinion-based or unanswerable because it requires mind reading. Stack Overflow works well with questions that can be answered with facts, and unless we’re lucky to find an authoritative source for the design criteria of java.time, I’m afraid that this question can’t. — Ole V.V., Apr 25 '23 at 11:50
Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/253314/discussion-between-mohamed-afzal-and-ole-v-v). — Mohamed Afzal, Apr 25 '23 at 12:20

score 3 · Accepted Answer · edited Apr 26 '23 at 19:01

The ISO-8601 standard has changed over the years. To my recollection, the offset without colon was only originally supported when using the basic ISO format where separators are omitted, eg. either use "2022-03-17T23:00:00.000+00:00" or "20220317T230000.000+0000" but not a mixture (2004 version of ISO-8601).

For the method in question, java.time supports the common ISO format with separators. It was always the case that advanced use cases would need to create their own formatter, for which good support was designed. Key to the design of the method was the idea of round-tripping - the parse(String) method parses the output from toString() (unless using a specific formatter).

Why can’t Java 8 DateTimeFormatter.ISO_DATE_TIME handle offset zone without colon in it, ISO standards have 4 Offset formats.?

1 Answers1