NTP handles leap seconds in the "correct way" as far as it is defined, in that it makes UTC follow its defined values. The problem in the more general sense is you have two concepts of time, you have:
(1) The UTC/Civil definition of days being 24 hours, of 60 minutes of 60 seconds always, along with a formulae for dates that make up the Gregorian calendar (lets keep quiet for now about other calendars).
(2) You also want for various reasons staying in approximate synchronisation with the solar time - i.e. that at, say, 0 longitude the 12:00 local is, on a yearly average, the time the sun is overhead.
Now the second is define these days with extreme precision, but the Earth's rotation is variable and, worst of all, not quite predictable due to stuff moving around inside as well as tidal friction, etc.
The correct way to do all of this, of course, already is known and implemented in some systems that really matter, and that is to have you clock keeping "atomic" time that has no discontinuities, and then to apply a leap-second correction to get "civil" time. See:
That is exactly how the GPS satellites do it, and their own GPS time was in sync with UTC in 1980 and is now 16 seconds different.
What is a problem for more software when it comes down to second "accuracy" is the most computer libraries are based on (1) and:
a) They don't quite know how to deal with the 59-second or 61-second minutes that happen when you get a second removed/added.
b) Also to perform the conversion to/from atomic time you need the offset values and as they have to be updated as the Earth's motion is observed, so it is hard to do correctly on anything stand-alone. You then would need internet access and the security problem that brings, and the grief caused when in a few years some web developer stupidly change URLs of important data for no obvious reason when tarting up sites.
Finally, there is a project (which I have not checked/tried yet) to give you a local NTP "fluid time Wednesday" effect here: