[elfchief]

Actually, UTC -is- continuous. Even with leap seconds. At no point does UTC go backwards, at no point does a second happen twice, and at no point does a second change in length -- your 'extra' second happens as 23:59:60; when there's a negative leap second, the last second of the day is 23:59:58. UTC is not expressed or defined as an offset from some time in the past.

The real problem for computing is when UTC is converted to unix epoch time, which is defined as an offset from the past, and by definition has exactly 86400 seconds in a day, every day, so some provision has to be made for those extra (or missing) seconds. And -that- is where the problem happens. But it's not UTC that's mucking around with the definition of time, it's the standard representation of time that's used in modern computing that causes the problems.

That being said, UTC is still probably to blame for most of the problems, because it effectively requires knowledge of more than just a timestamp to understand when something actually happened. And that extra knowledge (the map of when leap seconds have happened before) changes often and irregularly. Epoch time could totally be redefined to include leap seconds, and that would solve lots of problems, but there's no practical way to distribute that updated leap seconds table to every system that would possibly need it...