From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/662 Path: main.gmane.org!not-for-mail From: Lloyd Zusman Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: Incorrect leap seconds in runit's log timestamps Date: Wed, 19 Jan 2005 18:56:47 -0500 Message-ID: References: <20050119203747.GA9017@greement.salle-s.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 1106179019 6091 80.91.229.6 (19 Jan 2005 23:56:59 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 19 Jan 2005 23:56:59 +0000 (UTC) Cc: =?iso-8859-1?q?Jo=EBl_Riou?= Original-X-From: supervision-return-901-gcsg-supervision=m.gmane.org@list.skarnet.org Thu Jan 20 00:56:51 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 1CrPgx-0005zs-00 for ; Thu, 20 Jan 2005 00:56:51 +0100 Original-Received: (qmail 11067 invoked by uid 76); 19 Jan 2005 23:57:11 -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 11061 invoked from network); 19 Jan 2005 23:57:11 -0000 X-Injected-Via-Gmane: http://gmane.org/ Original-To: supervision@list.skarnet.org Original-Lines: 60 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: hippo.asfast.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) Cancel-Lock: sha1:iYX9qi0o+6pkrvZD5F2BhLoVWwk= Original-Sender: news Xref: main.gmane.org gmane.comp.sysutils.supervision.general:662 X-Report-Spam: http://spam.gmane.org/gmane.comp.sysutils.supervision.general:662 Joël Riou writes: > [ ... ] > > 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*. Ah ... OK. So now I know where the delta of 10 seconds comes from. [sensation of fog lifting] Thanks. > [ ... ] > > 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...] Well, I'm using 'clockspeed' to keep my system clock on TAI, and that clock is indeed in sync with this resource (at least that's what the clockspeed utilities seem to say). However, the 'runit' timestamps are 10 seconds later than what 'clockspeed' tells me. Perhaps 'clockspeed' uses 1970-01-01@00:00:00Z as it's base instead of the correct 1970-01-01@00:00:10Z TAI starting point? Before I go over to the 'tai' mailing list, I want to make sure that I understand why 'runit' and 'clockspeed' seem to be using different starting times, so I can try to sound at least halfway knowledgeable about this when I pose my question on that list. Any thoughts as to why 'runit' and 'clockspeed' are out of sync? > 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. Well, I left the ntpd world and I'm sticking with 'clockspeed'. But given this 10-second discrepancy, it too seems to have its problems ... or at least some confusing complications. -- Lloyd Zusman ljz@asfast.com God bless you.