Date: Fri, 26 Oct 2001 18:09:56 -0700 From: Mike Smith <msmith@freebsd.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <200110270109.f9R19uv06023@mass.dis.org> In-Reply-To: Message from Matthew Dillon <dillon@apollo.backplane.com> of "Fri, 26 Oct 2001 17:38:29 PDT." <200110270038.f9R0cT442082@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> :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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200110270109.f9R19uv06023>