Stephen, I am not a wide-scope wizard in this area. I may not be even a narrow-scope wizard.
Having said that, this is a problem with the timescale used by different systems. UTC has leap seconds, but POSIX (for example) does not address how to deal with them. On Unix systems, NTP will apply the leap second at the rate of 1 second per second at the end of 23:59:59. On Windows, NTP will apply the leap second at the rate of .5 seconds/second starting at 23:59:59, which means the leap second correction is still in-process until 00:00:01. One can also apply this smear over longer periods, like perhaps a full day. The correction can be applied linearly or more smoothly: http://googleblog.blogspot.in/2011/09/time-technology-and-leaping-seconds.html http://stackoverflow.com/questions/11279992/math-behind-google-leap-second-smear-formula You probably know way better than me that there is a difference between frequency synchronization and time synchronization, and sometimes there is a problem trying to do one with the other. Having said this, http://nwtime.org/projects/timestamp-api/ is working on its General Timestamp API project, to do a better (sufficient, even) job of accurately and precisely generating timestamps. This includes cases where the system is applying a correction, be it a general offset correction or a leapsecond correction. NTF needs participation and support to develop the General Timestanp API project - I encourage all folks interested in this to help make this happen. -- Harlan Stenn <[email protected]> http://networktimefoundation.org - be a member! _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
