That is a different problem. You usually work with timestamps and then convert the time to local time only when displaying it or doing calculations that depend on the particular timezone. So it's less of a problem, since at lower levels you don't have the concept of timezone (you may never have it, for example on embedded devices).

But if UTC shifts, it's another story. You assume the UTC (or UNIX) time to be a monotonic counter, and usually it's used this way, for example you compare two timestamps to know what definitively happened before another thing. Surely you don't take into account leap seconds... this is the problem.

Leap seconds wouldn't be that much of an issue if the time is only increased, you have one more second, it's the higher level implementation that has the concept of time to (maybe) deal with it. But they become an issue if they can take behind the UTC clock since it can generate all sort of strange bugs.

It's even a worse solution to make the duration of a second in a day longer or shorted, because you preserve the counter value, but you no longer can rely on the fact of 1 seconds being 1000ms long!

By the way the concept of leap second is nonsense to me. What is the purpose? If the purpose is to keep in sync the time with the rotation of the earth, nobody will ever notice an error of a couple of seconds, or even minutes. It makes more sense to take the current definition of a second, and then wait till the error is noticeable to an human being (let's say an error of 15 minutes, that would take centuries and we will probably far gone from the planet) and adjust it by shifting all the timezone for that amount of time.