From owner-freebsd-hackers Fri Aug 14 05:49:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA18080 for freebsd-hackers-outgoing; Fri, 14 Aug 1998 05:49:59 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from shrimp.dataplex.net (shrimp.dataplex.net [208.2.87.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA18075 for ; Fri, 14 Aug 1998 05:49:58 -0700 (PDT) (envelope-from rkw@Dataplex.NET) Received: from [208.2.87.5] (user5.dataplex.net [208.2.87.5]) by shrimp.dataplex.net (8.9.1/8.9.1) with ESMTP id HAA18118; Fri, 14 Aug 1998 07:49:07 -0500 (CDT) (envelope-from rkw@dataplex.net) X-Sender: rkw@mail.dataplex.net Message-Id: In-Reply-To: <199808132325.XAA00422@word.smith.net.au> References: Your message of "Thu, 13 Aug 1998 15:03:05 CST." <4.1.0.44.19980813150058.03f4dd80@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 14 Aug 1998 07:48:45 -0500 To: Brett Glass From: Richard Wackerbarth Subject: Re: 64-bit time_t Cc: Mike Smith , hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 6:25 PM -0500 8/13/98, Mike Smith wrote: >> >> I'd kind of like to do financial projections for my retirement and not >> >> have the calculations blow up, as they do now. >> > >> >time_t is a format for the system current time. As such, you're abusing >> >it mightily if you expect it to be a general-purpose time value. >> >> It's used throughout UNIX and UNIX programs as such. And rightfully so; >> it's silly to have multiple date formats. > >It's used throughout Unix and Unix programs to represent values of >'now' which may relate to the system time. It is abused to represent >time values which overlap this to some degree. > >It is not "silly" to have multiple date formats. It is *sensible* to >have multiple date formats, where each format is chosen for suitability >for its purpose. Brett, I have to agree with Mike on this point. Since I need time measured in picoseconds for the data in some scientific experiments and others need to measure geologic time, I guess that 64 bits is not enough. :-) If we follow your suggestion, EVERYONE would ALWAYS have to pay an extreme burden to process and store multi-precision time values. It is much more efficient to use the right tool, (or in this case, format) for the job at hand. "One size fits all" is really the wrong attitude. At best, it produces a sloppy fit. "One size fits none" is much closer to the truth. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message