The cosine adjustment that Google originally used is not the best: NTP aims to measure the difference in rate between the client’s hardware clock and real time, and it works best if the rates are fairly constant. With the cosine smear, the rate changes continuously! If you use a simple linear smear, NTP just has to cope with two small rate changes at the start and end of the smear.
The smear needs to be slow enough that NTP’s algorithms have time to react without overshooting; 24 hours is a reasonable choice tho you can go a bit faster. There’s some disagreement about when the smear occurs relative to the leap second; if the leap is in the middle of the smear the max offset is 0.5 seconds, but if the leap is at the end of the smear the offset is always slow. They were able to test the up-to-one-second-slow scenario in a system-wide live trial, whereas they could not do the same for the sign flip. I think if you can cope with a 0.5 second offset from real time then a 1.0 second offset should not be much more troublesome.