From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/658 Path: main.gmane.org!not-for-mail From: =?iso-8859-1?Q?Jo=EBl?= Riou Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: Incorrect leap seconds in runit's log timestamps Date: Wed, 19 Jan 2005 21:37:47 +0100 Message-ID: <20050119203747.GA9017@greement.salle-s.org> References: Reply-To: supervision@list.skarnet.org NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1106167091 22707 80.91.229.6 (19 Jan 2005 20:38:11 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 19 Jan 2005 20:38:11 +0000 (UTC) Original-X-From: supervision-return-897-gcsg-supervision=m.gmane.org@list.skarnet.org Wed Jan 19 21:38:01 2005 Return-path: Original-Received: from antah.skarnet.org ([212.85.147.14]) by deer.gmane.org with smtp (Exim 3.35 #1 (Debian)) id 1CrMaR-0005DS-00 for ; Wed, 19 Jan 2005 21:37:55 +0100 Original-Received: (qmail 9931 invoked by uid 76); 19 Jan 2005 20:38:15 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Archive: Original-Received: (qmail 9925 invoked from network); 19 Jan 2005 20:38:14 -0000 Original-To: supervision@list.skarnet.org Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i Xref: main.gmane.org gmane.comp.sysutils.supervision.general:658 X-Report-Spam: http://spam.gmane.org/gmane.comp.sysutils.supervision.general:658 Le mercredi 19 janvier 2005, Lloyd Zusman a écrit : > I believe that TAI and UTC are 21 seconds apart these days, although a > while ago, the discrepancy was only 11 seconds. rant { No, that is not true. First, a very good link on TAI/UTC questions is the following page by David A. Madore : . Nowadays, the "difference" between TAI and UTC is *precisely* 32 seconds (see ). But, for some obscure reason, the epoch is considered to be 1970-01-01 00:00:10 TAI on Unix systems whose clock is supposed to correspond to TAI timestamps (i.e. the time() function will return the number of seconds since that epoch (*), whereas with a GMT-time, this function is supposed to return the number of non-leap seconds since the epoch (**)). 32-10=22, so the difference between the result of time() in system with TAI/UTC-times seems to be *22*. (*) It is the case with right/foo (e.g right/Europe/Paris) glibc timezones. (**) Due to the fact that the difference between TAI & UTC was not an integer number of seconds in the beginning of the '70, the epoch considered by TAI and UTC systems do not match exactly [so why the hell 1970-01-01 00:00:10 TAI was chosen as an origin instead of 1970-01-01 00:00:00 TAI ?!] To be more specific, provided I understand well both runit and skalibs tai code, the tai functions assume that time()/gettimeofday() return the number of seconds since 1970-01-01 00:00:10 TAI, which I think is the Right Thing ; so if your computer uses another convention (UTC ?), you can get confusing results. [at this point, my brain is too damaged to check that this precisely explains your particular trouble...] } More seriously, the main trouble in this domain is that, as far as I know, ntpd assumes that the Unix time is ruled by UTC [which is quite confusing because the NTP protocol has allegedly some stuff to propagate the table of leap seconds from servers to clients]. I used to think about some dynamic library to LD_PRELOAD to ntpd to emulate UTC time() functions on a system with TAI time, but that would be very ugly. -- Joël Riou