If we used a unix-time-including-leap-seconds instead then the date/time conversion functions would need to have a little extra smarts (a table of leap seconds in addition to a timezone database) but most of the leap second related problems would not exist.

(We already deal just fine with months having variable numbers of days. Minutes having variable numbers of seconds is obviously awkwardly rare from a testing point of view, but not fundamentally more difficult to get correct.)

The fundamental difference is that we can predict well in advance how many days will be in a given month, and the rules for calculating that number can be implemented with a short lookup table and a few modulo operations.

The lookup table for past leap seconds, however, is already longer than 12 entries, and there is no way of calculating the length of all future minutes.

On the other hand, the problem may be simpler than keeping track of changes to timezone definitions, since there are hundreds of jurisdictions that can unilaterally change those.