On Thu, Jul 5, 2012 at 2:02 PM, Roy <r.engehausen@gmail.com> wrote:
On 7/5/2012 10:42 AM, Steve Allen wrote:
On Thu 2012-07-05T10:26:22 -0700, Roy hath writ:
Lets see. There have been nine leap seconds in 20 years. So at the start of the next century the difference will probably be less than a minute
There is no predicting how large the decadal variations in LOD will be, but the difference should be somewhere between 1 minute and 3 minutes. Please see these charts and tables for how unpredictable it is. http://www.ucolick.org/~sla/leapsecs/dutc.html
Remember OpenTime is only for people who want their system clocks to ignore leap seconds. I don't include myself among the possible users of OpenTime.
Anyone who needs that can already do that using existing, deployed, and tested code and hardware and the GPS system time scale. Please see this worked example. Please do not invent yet another private time scale. http://www.ucolick.org/~sla/leapsecs/right+gps.html
...
So basically the concept of OpenTime is already implemented. All that's needed is a list of Stratum-1 servers that anyone can use.
From the website:
The scheme described in this web page uses a non-standard NTP server and a non-standard set of "right" zoneinfo files. The hard part is that the zoneinfo files must be hacked for GPS time and recompiled whenever a leap second is announced. Hopefully that recompile happens long before the leap second occurs. In this scheme the kernel does not have to handle the leap second. All of the handling of the leap second happens in the zoneinfo files. This is effectively the same as the bi-annual handling of daylight/summer time transitions. There are no real-time changes. Everything about the changes can be easily tested at any time by any user. ---- Wouldn't an easier way to be separate out the timescales where one is just 84600 seconds a day for the next 100 years, and another can keep accurate time for those that need that kind of accuracy? The POSIX standard can remain unchanged, and time can be monotonic. When the cumulative difference like like 5 minutes, we can have a huge pubic 5 year lead time thing to sync the timescales again. (Kind of like DST, no mater how publicly and how often and how well you tell people, folks will still show up to work late).
From the website again:
A system whose time_t is set using an NTP server giving GPS time (thus the kernel does not have to handle leap seconds) and which is configured to use the usual zoneinfo files will produce formatted date/time strings which are 15 seconds larger than official time. (The value 15 will increment at each leap second.) According to the developer forums this is the variation that Google has chosen for Android devices. ---- This seems like a good kludge. But a second is an arbitrary measure. We might as well add leap half seconds, or leap tenths of a second. I'd prefer leap minutes, so we can have these kinds of threads about 1/60th of the time :) Not that I don't find this entertaining.