Date: Fri, 26 Oct 2001 16:21:15 -0700 From: Bakul Shah <bakul@bitblocks.com> To: Dag-Erling Smorgrav <des@ofug.org> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Peter Wemm <peter@wemm.org>, arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <200110262321.TAA14697@ajax.cnchost.com> In-Reply-To: Your message of "27 Oct 2001 00:47:25 %2B0200." <xzp4romrpc2.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
> You are all morons. It is painfully obvious we cannot make do with God Dag to you too! > anything less than flobbosecond resolution, or we will seriously lose > when we transition to 7-dimensional computation lattices and find that > quadron fluctuations in the quantum phase-shift matrix is affecting > make(1)s ability to correctly determine whether Richard Stallman is, > in fact, Jesus reincarnate. Are we done with the bikeshed yet? Let's Let me guess. If you haven't encountered a problem it can't be real, right? > have those 64-bit time_ts now, please, and a coffee to go. Black, > please, with two lumps. As I have already said in an earlier email: - leave time_t at 32 bit on all freebsd machines - add nstime64_t that has ns resolution and will work for 584 years. - add zstime128_t *if* people want higher resolution and to represent longer timespan I don't want to have to change a bunch of exiting programs just because someone decided change time_t to a 64 bit quantity. That is why I would really prefer a new typename for a 64 time type. For file timestamps nstime64_t seems adequate to me for reasons I gave before -- may be mtime/atime/utime type should not be called time_t either. What the kernel does to accurately represent time is kernel's business but that kernel time type should not be considered time_t. But I don't believe a single time type can fit all so I am for multiple <resolution>time<size>_t types. Also, this is problem is not peculiar to FreeBSD and I really hope you (core) guys try to come to some consensus with other OS groups. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200110262321.TAA14697>