Then let's skip the leap hour too: just let UTC and UT1 diverge up to 86400 seconds and compensate that by changing the time zones when needed. Then, when the drift reaches 86400 seconds, the clock times are aligned again. At this point we just need to re-align the dates too, and this can be done by skipping February 29 on a leap year (which should be quite easy to implement in software).
Is that practical? Drift is slow and takes 1 min per century. Let’s say you can live with 10 minutes of drift. That leaves minutes [10-50] which is 4 centuries vs minutes [50-10] where it’s fine which is 2 centuries.
Also, if the problem were time zones, time zones already support non-whole hour shifts, so why not just apply the leap second into all time zones? The reason is that that isn’t what a leap second is. It’s kind of “how much time has elapsed since 1970 midnight” and that number is corrected for with leap seconds. Time zone offsets don’t help you here.
And timezones one hour wide impose about a +/- 30 minute fixed error (and sometimes larger) on top of that - the difference between local mean time and local civil time.
We have an implicit assumption for definitions of noon and midnight right now. I can't tell if that assumption will be there 1000 years later, but assuming that, UTC and UT1 can't really differ by much more than several hours.
