I don't have the need or motivation to implement this at the moment, but here is maybe a strategy:
add a lookup table of days with known leap seconds ((Year, Month) might be enough information because leap seconds always happen on the last second of the last day of the month in which they occur)
LocalTime can still assume 86,400 seconds per day, and can clamp and wrap accordingly
...but!! in the context of a date (e.g. LocalDateTime, Instant), the last second of the day can instead be clamped to 60 on specific days, similar to how we clamp dayOfMonth differently in different year/month combinations
addSeconds and addMilliseconds will need to be adjusted to see if they cross a leap-second boundary, when adding to a datetime
formatters should write 23:59:60.xxxx when applicable
It's debatable whether this is worth it. The lookup table will need to be updated each time a leap second is added, which doesn't happen on predictable intervals, and often doesn't happen with much advance notice. JS dates don't know or care about leap seconds, which makes the interop story a bit unclear.
What's more, most people don't care about to-the-second accuracy with datetimes, and industries that do (e.g. astronomy, high-frequency trading) usually have their own standards for dealing with times and aren't overly concerned with UTC.
I don't have the need or motivation to implement this at the moment, but here is maybe a strategy:
(Year, Month)might be enough information because leap seconds always happen on the last second of the last day of the month in which they occur)LocalTimecan still assume 86,400 seconds per day, and can clamp and wrap accordinglyLocalDateTime,Instant), the last second of the day can instead be clamped to60on specific days, similar to how we clamp dayOfMonth differently in different year/month combinationsaddSecondsandaddMillisecondswill need to be adjusted to see if they cross a leap-second boundary, when adding to a datetime23:59:60.xxxxwhen applicableIt's debatable whether this is worth it. The lookup table will need to be updated each time a leap second is added, which doesn't happen on predictable intervals, and often doesn't happen with much advance notice. JS dates don't know or care about leap seconds, which makes the interop story a bit unclear.
What's more, most people don't care about to-the-second accuracy with datetimes, and industries that do (e.g. astronomy, high-frequency trading) usually have their own standards for dealing with times and aren't overly concerned with UTC.