The grammar element time-second may have the value "60" at the end of months in which a leap second occurs

[Megaprog]

Please, look https://tools.ietf.org/html/rfc3339 examples:

1990-12-31T23:59:60Z - This represents the leap second inserted at the end of 1990.
1990-12-31T15:59:60-08:00 - This represents the same leap second in Pacific Standard Time, 8 hours behind UTC.

ITU cannot parse these date-times.

RFC3339 documentation says:

The grammar element time-second may have the value "60" at the end of
months in which a leap second occurs -- to date: June (XXXX-06-
30T23:59:60Z) or December (XXXX-12-31T23:59:60Z); see Appendix D for
a table of leap seconds. It is also possible for a leap second to be
subtracted, at which times the maximum value of time-second is "58".
At all other times the maximum value of time-second is "59".
Further, in time zones other than "Z", the leap second point is
shifted by the zone offset (so it happens at the same instant around
the globe).

[ethlo]

I have investigated this a bit, and the problem is that this library depends on the Java 8 java.time library which does not support leap seconds. This is very evident if you look at the `ChronoField class which contains this code:

SECOND_OF_MINUTE("SecondOfMinute", ChronoUnit.SECONDS, ChronoUnit.MINUTES, ValueRange.of(0L, 59L), "second"),

There is no support for holding such a value in the underlying library, and thus I have no straight-forward path to implement this.

As you can see this will also fail:

final String leapSecondUtc = "1990-12-31T23:59:60Z";
OffsetDateTime.parse(leapSecondUtc);

[ethlo]

I have a PR ready here: #5

All it really does is to ignore the 60-second value and replace it with 59 if the month, date, hour and second dictates that this might be a valid leap-second date-time. This may solve your issue if all you need is for the parser to not bork.

Please let me know what you think.

[Megaprog]

I have investigated this a bit, and the problem is that this library depends on the Java 8 java.time library which does not support leap seconds. This is very evident if you look at the `ChronoField class which contains this code:

SECOND_OF_MINUTE("SecondOfMinute", ChronoUnit.SECONDS, ChronoUnit.MINUTES, ValueRange.of(0L, 59L), "second"),

There is no support for holding such a value in the underlying library, and thus I have no straight-forward path to implement this.

As you can see this will also fail:

final String leapSecondUtc = "1990-12-31T23:59:60Z";
OffsetDateTime.parse(leapSecondUtc);

There is a way to parse leap second by java.time look at: https://stackoverflow.com/a/55310635/1306553

[ethlo]

Yes, I'm well aware, thank you. However, there is no way to store the result of it, as OffsetDateTime does not support any values outside of [0-59]. ITU can easily parse the number 60 as well as 59 (and it currently does), however, the error occurs when you try to put those values into OffsetDateTime.

[Megaprog]

ok then

[ethlo]

Hi again! I was curious what is your use-case for this. How are you encountering these leap-second date-times? Will this patch work for you?

[ethlo]

This has now been solved by introducing a LeapSecondException which is thrown to signal that there was a leap second that was attempted to be parsed. This change has now been released in version 1.3.0.