I do not know the code; nevertheless, I disagree. The moment you allow for leap seconds, you need to visit your apps. Can they display x hours, y minutes, 60 seconds? (IIRC, 61 seconded can occur, too). You also need to consider how and how often you update your 'current number of leap seconds' store, you have to add 'across leap seconds' checks to all duration calculations, in addition to 'across DST change' checks, etc. You also will have to decide, on a per call basis, what the programmer intended with a call ('one day later' or 'same time on the next day' or 'about 24 hours later, also on the whole hour'?) oftentimes, the programmer will not even have realized that these are different options. And heaven forbid if somebody does a calculation now for a future date, and some time later a leap second is announced for some moment before that future date.
I do not think a really nice design is possible here. There just are too many idiosyncrasies in time handling.
You are talking about display issues of leap seconds. That's a different problem from the one we're talking about, which is that the clock itself is wrong.
I do not think a really nice design is possible here. There just are too many idiosyncrasies in time handling.