From owner-freebsd-hackers Sat Aug 15 16:21:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA01180 for freebsd-hackers-outgoing; Sat, 15 Aug 1998 16:21:36 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from localhost.my.domain (ppp1718.on.bellglobal.com [206.172.249.182]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA01171 for ; Sat, 15 Aug 1998 16:21:31 -0700 (PDT) (envelope-from hoek@FreeBSD.ORG) Received: from localhost (tim@localhost) by localhost.my.domain (8.8.8/8.8.8) with SMTP id TAA01760; Sat, 15 Aug 1998 19:19:50 -0400 (EDT) (envelope-from ac199@hwcn.org) X-Authentication-Warning: localhost.my.domain: tim owned process doing -bs Date: Sat, 15 Aug 1998 19:19:50 -0400 (EDT) From: Tim Vanderhoek X-Sender: tim@localhost Reply-To: ac199@hwcn.org To: Terry Lambert cc: Tim Vanderhoek , grog@lemis.com, mph@pobox.com, brawley@camtech.com.au, hackers@FreeBSD.ORG Subject: Re: 64-bit time_t In-Reply-To: <199808152103.OAA22129@usr01.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 15 Aug 1998, Terry Lambert wrote: > The difference between accuracy and precision is often hard to grasp. Actually, it's high-school science, now. At least around here. :) > The problem here is that tickadj and friends are abstracted in such > a way that it looks like we are trying to make time_t accurate, > when those things which use time_t need only be precise. ^ should Exactly how many things should use it is, I suppose, up for debate. The settimeofday(2) shouldn't use it (it does). The localtime(3) shouldn't use it. Calculating your grandfather's age or your retirement savings shouldn't. > The value of time_t is as a monoclock value; ie: what it calls > "seconds" are actually "ticks", and it is useful to know "how many > ticks between X and Y" for things like making makefiles work. Do you mean for dependencies? They would work just as well if the filesystem stored accurate time information (although fs size might increase). :) Of course, any system trusting time data to store ordering information is subject to the timer's resolution. Ideally, the filesystem needs to provide an alternate way of storing this information. Practically, GNU and MS will ensure that software is always bloated enough that no computer will be fast enough to make us do anything. ;-) -- This .sig is not innovative, witty, or profund. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message