Date: Sat, 15 Aug 1998 19:19:50 -0400 (EDT) From: Tim Vanderhoek <ac199@hwcn.org> To: Terry Lambert <tlambert@primenet.com> Cc: Tim Vanderhoek <ac199@hwcn.org>, grog@lemis.com, mph@pobox.com, brawley@camtech.com.au, hackers@FreeBSD.ORG Subject: Re: 64-bit time_t Message-ID: <Pine.BSF.3.96.980815184549.1275A-100000@localhost> In-Reply-To: <199808152103.OAA22129@usr01.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980815184549.1275A-100000>