From owner-freebsd-stable Tue Apr 20 22: 2:42 1999 Delivered-To: freebsd-stable@freebsd.org Received: from enya.clari.net.au (enya.clari.net.au [203.8.14.116]) by hub.freebsd.org (Postfix) with ESMTP id E3D1415040 for ; Tue, 20 Apr 1999 22:02:25 -0700 (PDT) (envelope-from danny@enya.clari.net.au) Received: from localhost (danny@localhost) by enya.clari.net.au (8.9.2/8.8.7) with ESMTP id OAA26652; Wed, 21 Apr 1999 14:59:50 +1000 (EST) (envelope-from danny@enya.clari.net.au) Date: Wed, 21 Apr 1999 14:59:49 +1000 (EST) From: "Daniel O'Callaghan" To: "Chad R. Larson" Cc: Stephen Montgomery-Smith , stable@FreeBSD.ORG Subject: Re: Year 2000 In-Reply-To: <199904200055.RAA02113@freeway.dcfinc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 19 Apr 1999, Chad R. Larson wrote: > > > > Just wondering if the internet will face serious problems in 2038 > > because of all the `old' unix software still running it. > > I believe the assumption is that within 30 years, UNIXs will have > moved time_t from a "long" to a "long long" (or "quad" or whatever). > Most the commercial vendors (HP-UX, Solaris) have already done this as > part of their 64-bit UNIX initiatives. In my y2k review of the FreeBSD sources, I found *lots* of comments to the effect that the code was written to work to 2037 and not beyond. Unfortunately, progressing beyond 2037 is not going to be simply a matter of changing the definition of time_t and doing 'make world'. What we really need is a date calculation library which handles all of the calculations which are done in a plethora of ways now, so that no-one needs to make up a half-baked method again. (and yes, I know that "no-one needs" != "no-one will") Danny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message