What should an ISO-8601 date look like at exactly 0 milliseconds?

Question

I am calling a web service that formats dates using ISO-8601 (as far as I can tell).

Here is the pattern I am using the parse the dates (I'm using Jackson to de-serialize the response):

yyyy-MM-dd'T'HH:mm:ss.SSS'Z'

Most of the time, the service returns dates that look like this:

2022-08-19T22:48:17.228Z

However, the service occasionally returns a date like this:

2023-09-12T00:18:25Z

I think this occurs when the number of milliseconds is exactly 0.

Is this expected behavior for ISO-8601 dates, or is the service doing something weird?

Answer 1

According to this

This profile does not specify how many digits may be used to represent the decimal fraction of a second. An adopting standard that permits fractions of a second must specify both the minimum number of digits (a number greater than or equal to one) and the maximum number of digits (the maximum may be stated to be "unlimited").

Meaning that the "mask" used by the service considers the 3rd digit of the milliseconds to be optional, and when it is 0 it will hide the value altogether.

A fix would be to check the length of the date and add a 0 before the last character (assuming its always Z)

Answer 2

"... What should an ISO-8601 date look like at exactly 0 milliseconds? ..."

You can utilize the Date class, which has a constructor method for milliseconds.

SimpleDateFormat f = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSS'Z'");
out.println(f.format(new Date(0)));

1969-12-31T19:00:00.000Z

"... the service occasionally returns a date like this:

2023-09-12T00:18:25Z

I think this occurs when the number of milliseconds is exactly 0. ..."

No, this is a valid date and time.
The hours are 0 – 23, where 0 is 12 am.

"... Is this expected behavior for ISO-8601 dates, or is the service doing something weird? ..."

The blame would be on the service, the ISO 8601 is just a notation, or code.