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>