I decided to test my assumptions about the clock's display accuracy today. I can now say that the "zero tenth" display update completes in 186 µs from the rising edge of the PPS pulse.

I did this by displaying the PPS signal and the display controller !CS pin on my scope. By triggering on PPS I could see the time difference between the rising edge of PPS and the last rising edge of !CS (which is at the end of the SPI write cycle and causes the display to update at some short, but unspecified time thereafter).

In the picture you can see 9 SPI write cycles starting roughly 100 µs after the rising edge of PPS. There are 9 because the first of them writes to the digit decode mask register, then 7 write to the "real" display digits and the last one to the "misc" digit that controls the colon and AM/PM LEDs.

Each tenth of a second will have somewhat less latency, because it's interpolated inside of a relatively tight loop in main() and because it's a single SPI write solely to the tenth digit. But it's impossible to determine its accuracy using a method like this as there is no synchronizing tenth-of-a-second element available for comparison.

This is a bit longer than I had estimated. I can only conclude that I had underestimated how long all of the DST and timezone fiddling takes.

So the official specification now is that the clock is within 200 µs of GPS time. This gives 14 µs grace to the MAX6951. In truth, most display updates will "finish" far sooner than this because the display is updated least-significant-digit first. That means that for 59 minutes out of the hour the hour digits will not change, meaning that those writes don't count. Backing down further, 59 seconds out of each minute the minute digits don't change, and the tens-of-minutes digit only changes on 6 out of the 60 per hour of those that do.

EDIT:

I spoke with Maxim about the MAX6951's update latency. They claim that the time between rising !CS and the data being available is on the order of 25 ns or so. That implies that the ~1.6 µs worst-case refresh cycle duration (~600 kHz) is going to dwarf whatever update latency exists. So we can say that the total update latency is very close to the measured ~180 µs, and that 200 µs is actually too generous. Still, better to under-promise and over-deliver.