replacing crystal with TCXO

Very interesting. I ran your test on an Uno board and a Sparkfun "Dead-On" RTC breakout board. I had to make a few changes to run my board (because I plug the RTC board right into pins 8 thru 13).

Here's the result I got:

RTC glitch test.

01:59
01:59
01:59
01:59
01:59
01:59
01:59
01:59
01:59
01:59
01:59
01:59
01:59
01:59
01:59
01:59
01:59

This is the change I made to your sketch to be able to run it here:

#define BURST_READ  0    // set to 1 for burst read, 0 for one at a time

//#define SS_PIN    10
//#define CLK_PIN   13
//#define MISO_PIN  12
//#define MOSI_PIN  11

#define VCC 13
#define SQW 12
#define CLK_PIN   11
#define MISO_PIN  10
#define MOSI_PIN  9
#define SS_PIN    8

void setup()
{
  Serial.begin(115200);
  Serial.println("\nRTC glitch test.\n");

//////////////////////////////////// added /////////////////////////////////////
  pinMode (SQW, INPUT); // prevent possible contention with SQW output
  digitalWrite (VCC, HIGH); // steal power from a pin
  pinMode (VCC, OUTPUT);
  delay (1000); // let it stabilize?
//////////////////////////////////// added /////////////////////////////////////

Everything else was unchanged.

BTW, the reason I wrote my library using bit-bang SPI was so that ANY pins could be used. Plus, I saw no need to tie up a high speed hardware SPI port that something else could make better use of... and as you said reading an RTC doesn't require speed anyway.

Anyway, as you know my code reads or writes all 7 registers at once (and of course the problem is only on the read side).

All I need to do is read the 7 registers once, then do a second read but instead of saving the readings, I would COMPARE the results. Any mismatch would simply trigger another read/compare cycle.

I think that would make the problem go away in a bulletproof manner, what do you think?