John H. Robinson, IV wrote: > Andrew Lentvorski wrote: >> John H. Robinson, IV wrote: >>> Those shops should be using clockspeed then. >>> >>> http://cr.yp.to/clockspeed.html >>> http://cr.yp.to/proto/utctai.html >> Why use these? >> >> Especially since A) OpenNTP exists and B) NTP-type systems are >> notoriously sensitive to very tiny details. > > Because NTP does not use TAI. > > TAI does not have the problem with leap seconds that POSIX > specifications do. > > TAI, Temps Atomique International (French for International Atomic > Time), measures real time. One second of TAI time is a constant > duration defined by cesium radiation. TAI has been measured > continuously since 1955 and is the foundation of all civil time > standards. > > TAI times are identified by year, month, day, hour, minute, and > second. There are exactly 86400 TAI seconds in every TAI day. TAI > days are labelled by the Gregorian calendar. > > ... > > UTC, Coordinated Universal Time, is based on TAI, and very similar to > it, except that UTC has leap seconds every year or two. For example, > here's how UTC and TAI handled the end of June 1997: > > 1997-06-30 23:59:59 UTC = 1997-07-01 00:00:29 TAI > 1997-06-30 23:59:60 UTC = 1997-07-01 00:00:30 TAI > 1997-07-01 00:00:00 UTC = 1997-07-01 00:00:31 TAI > > ... > > For many years, the UNIX localtime() time-display routine didn't > support leap seconds. In effect it treated TAI as UTC. Its displays > slipped 1 second away from the correct local time as each leap second > passed. Nobody cared; clocks weren't set that accurately anyway. > > Unfortunately, xntpd, a program that synchronizes clocks using the > Network Time Protocol, pandered to those broken localtime() > libraries, at the expense of reliability. > > ... > > By resetting the clock at each leap second, xntpd extracts a correct > UTC display (except, of course, during leap seconds) from the broken > localtime() libraries. Meanwhile, it produces incorrect results for > applications that add and subtract real times. > > ... > > It's easy enough to fix xntpd. It's also easy to fix localtime() to > handle leap seconds. In fact, some vendors have already adopted > Olson's time library. > > The main obstacle is POSIX. POSIX is a ``standard'' designed by a > vendor consortium several years ago to eliminate progress and protect > the installed base. The behavior of the broken localtime() libraries > was documented and turned into a POSIX requirement. > > Up to you what you chose to do. My systems run NTP, but I have the > luxury of not having to worry about time monotonicity. > > Additionally, we are talking about a step change at boot time, before > the system can even be considered ready. > > Linux boot order: > 0. kernel loads > 1. system time set from hardware time > 2. network comes up > 3. ntpdate creates step change to known good time source > 4. ntpd initiates clock skew to maintain steady time > 5. applications are ready to be started > > Time monotonicity is available after step 4. Actually, after step 3, but > the system time's idea of a second may not match the rest of the world's > idea. This is what step 4 is for: to keep everything in sync. > > If the application requires time monotonicity before any clock > synchronisation can occur, someone had better be spending a lot of money > on very good hardware clocks. And a very good kernel. Something. >
So, if i understand, TAI is exact elapsed time (from 1955) based on 88400 s/day. I presume it includes leap year days. But it does not recognize any leap seconds (ever?). POSIX base time (incl. ntp) is maybe "calendar" time, that is it includes leap seconds, which is supposed to diddle clocks every now and then to keep the equinoxen meaningful (my characterization -- please correct). If that's about right, then are you arguing that we should _never_ adjust the calendar to finer precision handled by leap year algorithms? Wouldn't that lead to confusion a few centuries ;-) down the road? Or maybe I've got it wrong (not unusual). Regards, ..jim -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
