From owner-freebsd-hackers Thu Aug 13 23:27:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA00584 for freebsd-hackers-outgoing; Thu, 13 Aug 1998 23:27:23 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from word.smith.net.au (castles215.castles.com [208.214.165.215]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA00560 for ; Thu, 13 Aug 1998 23:27:15 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.8) with ESMTP id XAA00422; Thu, 13 Aug 1998 23:25:10 GMT (envelope-from mike@word.smith.net.au) Message-Id: <199808132325.XAA00422@word.smith.net.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Brett Glass cc: Mike Smith , hackers@FreeBSD.ORG Subject: Re: 64-bit time_t In-reply-to: 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: Thu, 13 Aug 1998 23:25:09 +0000 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > At 12:24 PM 8/13/98 -0700, 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. time_t is too imprecise for many things (hence struct timeval) and too limited in range for others (eg. your application). Neither of these mean that it's not suited to its correct usage. > >Might I suggest that you should consider using something with perhaps a > >slightly reduced precision, like anyone else that does work involving > >longer timeframes? > > This would create an incompatible notation and would make life much more > difficult than fixing the basic problem. Surely you jest. Fixing *just* your application is "much more difficult" than fixing every other application that uses time_t correctly? I think not. > >time_t is not a hammer. > > Nope, but I don't intend to carry an entire box of tools to screw in a light > bulb.... ;-) Funny, that's what Unix is. A big box full of tools. Pick the right one for the job, and you'll bruise much less often. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message