Yes, I used to have two Cesium standards in my basement, and that allowed me to make FreeBSD the first kernel which could be wrangled to nano-seconds.
These days timekeeping is much more routine and standard hardware, but even if you miss out on LORAN-C and time-by-telephone and leap-seconds, it can still be lots of fun.
Once you get into it, you can look at the log files, call the remote site, and tell them that somebody left the door to the server room open again.
How ?
A temperature difference of 1°C more or less translates to a 1PPM shift (one microsecond per second) in the kind of crystals used for modern motherboard clock chains.
Most air-con systems will oscillate a couple of degrees with approx 20minute period (gentlemen: Tune your PLLs), so a sudden 5 PPM excursion is either a broken air-con or a door left open.
One of the most amazing feats of applied time-nuttery was Steven J. Murdochs work on fingerprinting the timezone of remote servers, based on their TCP sequences numbers.
(Amongst other things, he found out that a lot of Tor nodes were most probably located in north-eastern USA.)
I eventually got it all to work 'in the lab' but nowhere near stable or accurate enough for a real life application. This was all done at very low radio frequencies with super low radiated power (under the license limits) and that of course complicated matters greatly.
The big game changer was to get hold of an atomic clock that I could run locally. That takes the sting out of synchronizing with external sources (such synchronization usually involves a PLL and while the long term stability is amazing over the short term it usually is quite terrible [1]) and using a relatively affordable SDR I was finally able to do this with enough precision to be able to differentiate between the ground conducted signal and the 'airwave' for one of the EU atomic clocks (DCF-77). It was really neat to see the effect of the day/night cycle on the propagation of the signal (exactly as predicted) as validation.
And that's precisely the problem: when you need very short term stability that nicely couples into longer term stability you have your work cut out for you.
Another downside of this kind of project is that to collect the data you are always looking at a minimum of 24 hours or so of sample time and at high enough rates that really adds up. Suddenly you need media that are never going to hiccup during long sequential writes and it turns out that's not a simple problem either. Before long you'll be messing around with the buffering deep inside of GNU Radio (which is amazing piece of software by the way).
But: when it finally works it is extremely satisfying. To see a clock driving a frequency counter and a non-derived clock that lists 9 zeros with a 100 second sampling window is pretty cool.
They are very well aware of both the short-term and long-term effects that they have to compensate for. And getting that both smooth and accurate down to the nanosecond level is particularly hard.
They are not the only vendor of Stratum-1 NTP time servers (on the AWS EC2-Chronos team, we called them Primary Time Appliances), but I think they are one of the best. If not the best. And a friend and former co-worker of mine from EC2-Chronos is now working there.
Also vaguely related, the precision clock kit by Mitxela - https://mitxela.com/shop/clock4
Then there's the EFOS3 Hydrogen Maser by https://www.efos3.com/
There is a very deep rabbithole in here.
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...
For time nuts, it's always time...
If you don't get it, then, you just don't get it...