The UNIX-NTP real world compromise

Previously:

Leap Seconds
State of the Standards
What Matters When measuring

It's inescapable that a real world solution will need to deal with applications that cannot generate nor accept UTC.  Some may be in compliance with one of the self-contradictory standards, or be earlier versions of software that complied with a standard that was at that time ambiguous or self-contradictory.  They may have simply ignored the standards also.  SQL92 may win the record for first to be correct, but it doesn't take long to find widely used implementations of SQL that do not support UTC properly.  And some applications just made up their own formats because there was no standard applicable.

The UNIX-NTP compromise is based on the following assumptions:

1. The scope is an operating room scope, so a large phase error relative to real UTC is permissible but only the small phase error is permissible between machines within the scope.  The frequency error needs to remain very small within scope, but can be larger when compared with UTC.
2. The clocks are all under control and all synchronized to a common operating room scope source.  No exceptions can be allowed.  The clocks might be external clocks or they might be operating system clocks.  Any clock used in the data gathering must be controlled and synchronized.  (This can be done without too much cost if you are careful.)
3. The applications are a mix of UTC and non-UTC supporting applications.  So the clock time must never show more than 60 seconds in a minute, even during the leap second of UTC.

You do this by deliberately selecting an inaccurate but well behaved clock for the operating room scope.  If you intentionally slow down the scope clock by 0.01% starting 5000 seconds before the leap second, your scope clock will be at 59.5 seconds when UTC is at 60 seconds.  This is 500 ms slow, but that's fine for administrative scope.  All of the operating scope clocks can remain synchronized to this slower clock to within 10ms.  The frequency error of 0.01% is well below the frequency error limit for operating scope.  Then, when UTC time is at 60.5 seconds, the scope clock rolls from 59.99 to 00 in the next minute.  Suddenly, instead of being 500ms slow, it's 500ms fast relative to UTC.  But this is OK because UTC is only in the administrative scope.

Eventually, about 5000 seconds after the leap second, the scope clock can be returned to normal speed and continue to track UTC.

This trick will not work if UTC needs to be within operating room scope.  Fortunately, I know of no medical reason to have UTC within operating room scope.  Administrative scope is adequate.  The UNIX-NTP trick is actually the default configuration for many UNIX NTP systems, because operating system scopes like this are very common in many applications.

The most demanding and difficult part of making this work is:

1. Having local system clocks with NTP support that permit frequency control to this level.  Almost all PC hardware and other hardware is capable of it, but the default clock drivers for most versions of Windows do not support this level of control.  (I haven't checked Vista, but non of the others have this degree of control).  So Windows based systems need to have the default windows clock drivers replaced with special NTP capable drivers.  These are available from third party vendors.
2. You need to find and fix every machine without exception.
3. You will have significant difficulties later if you need to synchronize this data with other external data and need better than administrative scope synchronization.  The clocks are intentionally not matching UTC.  You will need to tolerate these mismatches.

Those conditions are reasonable, and there are thousands of little islands of synchronized time that are using the UNIX-NTP solution.