Time and RTC libs - question on date and time integrity

odometer:
I'm sorry if I didn't make myself clear. What I aim to do is to have the clock show civil time, with all its irregularities, and to be as independent from outside sources of time-related information as possible. I am using a Chronodot, but do not count this as an "outside source"; the outside sources to which I refer are mains frequency and NTP / radio / GPS signals. Ideally, I set the clock once in the entire duration of its existence, though in practice, I will almost certainly need to make occasional adjustments of a few seconds.

I would prefer to be able to tell the clock, "leap second coming at end of month XXX", and have it correctly insert that at the right time, as well.

Pardon me for asking, but what part of my recommendation runs counter to your stated desires for this project? You wanted to avoid flickering displays, I addressed that issue by minimizing the CPU overhead associated with querying the Chronodot to once a day. That configuration also allows you maximum CPU capacity for other features, such as showing seconds in 1/2 increments.

If you are not familiar with the SQW output that the Chronodot features, now may be a good time to re-read the DS3231 datasheet and Atmel 328P interrupts. I have used the SQW output for my projects, it makes timekeeping much easier without a lot of overhead. The only downside as I see it are the (IIRC) 51-odd instruction cycles that it takes to drop into a interrupt routine. That said, 51 out 16 Million cycles per second is a pretty small percentage allowing your MCU to do other things 99.9997% of the time.

With careful monitoring and the adjustment of the aging trim (see datasheet) you may be able to minimize clock drift.

As far as the insertion of leap seconds go, here is a quote from Wikipedia (for what that's worth):

Because the Earth's rotation speed varies in response to climatic and geological events, UTC leap seconds are irregularly spaced and unpredictable. Insertion of each UTC leap second is usually decided about six months in advance by the International Earth Rotation and Reference Systems Service (IERS), when needed to ensure that the difference between the UTC and UT1 readings will never exceed 0.9 second. Between their adoption in 1972 and June 2012, 25 leap seconds have been scheduled, all positive.

(emphasis mine).

So in forty years, 25 seconds have been added at irregular intervals. My suggestion would be to worry about clock drift instead, the DS3231 is not nearly that accurate. Ideally, it'll be around 2PPM without accounting for aging, reflow soldering, etc. That's 63 seconds per year or ~5 seconds per month, assuming a non-random distribution of the error.

If I had too much time on my hands, it would make for an interesting experiment to see how accurate the DS3231 can be made through careful adjustment of the aging trim. For example, by connecting it to a radio time stamp circuit and comparing the 'should' vs. 'actual' seconds elapsed over a two month period and auto-adjusting the trim accordingly.