In message: <[EMAIL PROTECTED]> Rob Seaman <[EMAIL PROTECTED]> writes: : Poul-Henning Kamp wrote: : : > Rob, If you feel uncomfortable with calling leapseconds : > discontinuities, then we can use the term arrhythmia instead. : : Which raises the question of why projects requiring an interval time : scale lacking in such arrhythmias would have selected UTC in the : first place.
The real world often times requires both kinds of time keeping, with correlation back and forth between all the timescales. The customers want to deal with times in UTC. To get an effective, high precision time system, you need to count seconds in a sane way (UTC isn't a sane way for this purpose) so some conversion between this count and UTC is needed. The problem is that most interesting systems have a need to do things based on UTC time of day, as well as in a time scale that has none of the complications of the unpredictable UTC implementation we have today. So you can't just 'pick one' because real-world systems need to use different ones for different things, and they also need to translates events from one timescale to events in the other timescale. Let me give you a concrete example. Let us say we are measuring a number of atomic clocks against one another. We get the measurements and those measurements are in a monotonic timescale that is defined as PPS's from some epoch (or number of 5MHz or 10MHz ticks from some arbitrary epoch). We get data from GPS, which has a similar timescale. We compute the clock states and deside that we need to steer one of the clocks. These algoritmns are very much elapsed time sorts of deals. So we schedule a time to steer it, and then note the time when we are done steering it. Since we cannot easily get the GPS or timer times without interfereing with the operations of those subsystems (maybe because the steering system and GPS system are on dufferent cpus), we get the system time when the steer starts and when the clock tells us the steer is complete (since a steer isn't an instantaneous event). Since this system also is an ntpd server, that system time is in UTC. Now we have to convert UTC into the internal timescale so that the algorithms know when the steer happened and can take that into account for their next round of measurments and decision making. To make this all work out well, one has to have perfect leap second knowledge and all the special case code you have for dealing with the arrhythmia of a leap second has to work perfectly. Anything that can be dobe to make things more perdictable helps out quite a bit... Warner