Bug with leap second parsing ISO 8601 about time

[jhpratt]

Two things here:

1. Leap seconds are not properly handled. A trivial demo shows this using a leap second that has actually occurred. This is a bug and will be fixed.
2. If you are using 2023-12-11T11:31:60.000Z as your test case, don't. Leap seconds have only occurred as the last second of either half of the year (i.e. Jun 30, Dec 31 at 23:59:60). December 11 obviously is not that. Theoretically they can happen at the end of any month (per definition of UTC), but in reality preference is given to June or December, with March and September being alternates.

[dracarys18]

2. @jhpratt This is not a testcase this is from our logs

[jhpratt]

I would suggest looking into your logging system in that case, as it's producing invalid values.

[dracarys18]

@jhpratt So this is generated by this function and I got this exact value from logs which was throwing deserialisation error.

[jhpratt]

Time holding a seconds value of 60 would be the only way for the crate to output that string barring a hard-coded literal in the format description. After quickly checking what is called all the way down, there's no way that that is what's causing this. The seconds field is ultimately calculated in Time::adjusting_add, and it's quite easy to verify that the implementation there is correct.

[jhpratt]

Fixed on main. It will be released shortly.