Date: Fri, 14 Aug 1998 07:48:45 -0500 From: Richard Wackerbarth <rkw@Dataplex.NET> To: Brett Glass <brett@lariat.org> Cc: Mike Smith <mike@smith.net.au>, hackers@FreeBSD.ORG Subject: Re: 64-bit time_t Message-ID: <l03110701b1f9da5b1ecf@[208.2.87.5]> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?l03110701b1f9da5b1ecf>