In message: <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Michael Sokolov) writes: : The people who complain about leap seconds screwing up their interval : time computations are usually told to use TAI. They retort that they : need interval time *between civil timestamps*.
Actaully, interval deltas are needed, but it is in TAI time. There needs to be, in the systems I've done, a timescale without leapseconds to keep all the measurements sane. In addition, many of the systems I've done have other functions they do also, some of which need to present UTC to the user. As much of a pita that leapseconds are today, having the converion between TAI and UTC (or put another way: between GPS and UTC or LORAN and UTC) would make these systems signficantly more difficult to get correct. There's also times when our systems take in events that are timestamped using UTC time, so we need to back correlate them to TAI or whatever internal timescale we're using. Some of that is because UTC is the standard for exchanging time, part of that is because the events in question are measured in whatever timescale is present on an NTP server. : To me that seems like : what they are really measuring as "interval time" is not physical : interval time, but how much time has elapsed *in civil society*. Hence : my idea of civil interval time that's completely decoupled from physical : time and is instead defined as the turning angle of the clock on the : Kremlin tower. Actually, you are wrong. The intervals is in the number of pps that have happened, or fractions thereof. Civil time does intrude because that's what people use right now to know time fo day. In the systems I've done, you need to know both. The requirements, as you may have noticed, for my needs aren't that the intervals be done in TAI (we use a variant of LORAN time due to historical accident, but with a 1970 epoch), but rather that UTC and these time scales be convertable between one another. Like I've said a number of times, saying 'just use TAI' isn't viable because of the conversion issue. Using TAI (or something with the no leapsecond regualrity that TAI gives) is necessary for the algorithms to work. However, external pressures also require that some things be done in UTC time and that some of the external sources of data use UTC time and that needs to be back correlated to the internal timescale that we're using. The algorithms, btw, basically integrate frequencies of different clocks, over time, to predict phase difference. In this case, you definitely want to use an interval, and not whatever weirdnesses civil time happened to do in that interval. Using an civil time interval would introduce errors in algorithms. These algorithms are used to estimate how well the clocks are doing, but other parts of the system need to play our UTC for things like NTPD and IRIG. Warner