Plus the time to learn a few modprobe commands. Perhaps run a few commands echoing numbers to random sysfs files. Perhaps learn WTF a 'Device Tree Overlay' is - a concept that's completely absent on x86 systems. You see, this is an 'I2C' device, so it doesn't plug and play like USB and PCIe devices do. It is much simpler, and hence for some reason more difficult. Perhaps your device tree overlay needs to be complied? Or maybe not. Perhaps you'll edit your modules file and your kernel command line. Of course that won't involve update-grub, why would you think that?
Don't forget to periodically check on your settings, just in case an OS update or something has disabled one of those settings.
Oh and of course you won't be able to fully test this over SSH, if the network is up NTP will have set your clock whether the RTC is set up right or not. As we've learned from the article, if you run into clock problems you might not be able to connect remotely.
Then simply invent a time machine so you can do all of this in the past, before the pi SD card fails and it drops off the network.
/s
I learned about the devicetree on a RPi too, but I didn't complain about it in a blog. When I bought my first RPi I expected to encounter problems and learn a lot from solving them. In fact, I expected it to be much much worse - so much worse that I even bought the RTC module even before the RPi arrived in the mail. Why didn't he/she think of that? It's because he/she is lacking the basics, the kid project with gpio leds and i2c sensors.
(And you can do the same thing were you write the time to the RTC before you have the correct time)
We found they drift less than 28s a year in standalone mode. Also, were repeatable within +-18ms when using a NTP client.
Microchip RTCs are harder to setup, but also seem to work just as well (ignoring the goofy epoch).
Chip shortage caused people to do unspeakable things.... ;-)
Are you sure you connected it correctly?