I've only barely started to look at what's actually "significant" with respect to clocking, but it appears that, with Windows and SNTP and probably with other systems using NTP or similar protocols, the actual system clock "accuracy" required for reliable network operation is on the order of +/-15 days. Within that range, your computer sends a "time stamp," the receiving server calculates an offset between its clock and yours, and the offset is sent back and forth with each message if a secure protocol is in use to assure that someone else hasn't poked their nose in. (Some commonly used secure transmission protocols do rely on stable timing.)

A proposed change to lengthen the "time stamp" will change the tolerance on how far off your computer can be to a little over +/-100 years. (They appear to be trying to accomodate those who don't know what century it is, so that people in Kansas won't be bothered with adjusting.)

Any "display clock" you may have, or may add, generally is only loosely related to your system clock that actually controls what goes on, and most display clocks don't display anything closer than the nearest second, or perhaps hundredth of a second. If your display needs correcting more frequently than about once per month to stay within the displayed bits, your internal clock is possible unstable and needs a new battery(?).

For those who actually need very accurate timing, a common setup in Windows (NT and later) checks a standard at frequent intervals, perhaps once per hour, until three or more "corrections" are within a certain small tolerance, and then automatically reverts to weekly checking. For programs of the types mentioned, setting once and checking weekly is probably more than adequate(?). You're unlikely to see a difference from using any of the secondary sites vs. going directly to nist or higher tier ones.

If someone has an actual requirement for more accurate time settings that somehow relates to reliable operation other than for "secondary time standard servers," perhaps, it would be interesting to know what it might be; but for "knowing what time it is" for ordinary communications one doesn't really need, and can't use, nanoseconds.

John