From owner-freebsd-arch Fri Oct 26 16:21:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ajax.cnchost.com (ajax.cnchost.com [207.155.248.31]) by hub.freebsd.org (Postfix) with ESMTP id 5BBAD37B401 for ; Fri, 26 Oct 2001 16:21:25 -0700 (PDT) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by ajax.cnchost.com id TAA14697; Fri, 26 Oct 2001 19:21:13 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <200110262321.TAA14697@ajax.cnchost.com> To: Dag-Erling Smorgrav Cc: Poul-Henning Kamp , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-reply-to: Your message of "27 Oct 2001 00:47:25 +0200." Date: Fri, 26 Oct 2001 16:21:15 -0700 From: Bakul Shah Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > 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 time_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