From owner-freebsd-arch Fri Oct 26 17:57:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id AD25A37B401 for ; Fri, 26 Oct 2001 17:57:10 -0700 (PDT) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id f9R19uv06023; Fri, 26 Oct 2001 18:09:56 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200110270109.f9R19uv06023@mass.dis.org> To: Matthew Dillon Cc: arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: Message from Matthew Dillon of "Fri, 26 Oct 2001 17:38:29 PDT." <200110270038.f9R0cT442082@apollo.backplane.com> Date: Fri, 26 Oct 2001 18:09:56 -0700 From: Mike Smith 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 > :And before anyone gets their knickers in a knot, remember this; all of > :the system time values (time_t, timeval, timespec) are meant to > :represent possible values of "now". Until "now" starts to blow them > :out, we have much bigger fish to fry. > : > Actually not quite true. We had to spend two weeks writing date/time > routines because the standard UNIX time_t routines couldn't go past > 2038. The time_t limitations are creating problems *NOW*. It messes > up simulations, forward looking views, contracts that start now and > end after 2038, astronomical programs, etc etc etc. I'll say it again, then. These programs should *not* be trying to use these functions. These functions are meant for manipulating time_t, which is a representation of "now". You should be using appropriate types and functions for your application. The system functions you are trying to use are not appropriate, and screwing up the system and all of the applications that use these functions just for your own selfish purposes is *not* appropriate. > Some of the turnkey > software I wrote 20 years ago is *still* *being* *used* today. And I bet you didn't spend enormous amounts of effort at the time trying to change the world so that your programs would still be working today, either. > We don't have 36 years to implement this, it's a problem that needs to > be solved now. I've already refuted this claim. > time_t's problem is similar to off_t's problem... it's best to get the > pain over with *NOW* rather then later. Then it's there when you need it. This is unsubstantiated. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message