From: Chris Croughton Newsgroups: comp.os.msdos.djgpp Subject: Re: Random implementation Date: Wed, 28 Jan 1998 16:47:24 +0100 Message-ID: <34CF530C.586@amc.de> References: <6am4ri$dtk$2 AT herald DOT Mines DOT EDU> <34CEF73B DOT 493E9C2D AT alcyone DOT com> NNTP-Posting-Host: bob.bob.bofh.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 26 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk Erik Max Francis wrote: > > ANSI C does not put any restrictions whatsoever on the encoding of the > the value returned by time. In many systems, it is the number of > seconds since some reference date. The ANSI/ISO standard says that it returns the "best approximation" to the current calendar time. Plauger points out that it could be argued that (for instance) 1980.01.01 00:00 is the "best approximation" available for a library. Note that type time_t (as returned by time()) is a type "capable of representing times" but need not be linear. For instance, MSDOS uses (for file times) a bit field where the date and time are encoded; this is not forbidden by the ANSI/ISO standard. > DJGPP is one of these systems, and as such, the value returned by time > will only repeat itself once every 2^32 seconds (srand takes an unsigned > int, which in DJGPP is the same size as a time_t). 2^32 s = 4.30 Gs = > 136 y. So it's hardly something to worry about. 136 years and 37.33 days (taking leap years into account), or around 8am on 7th February 2106 for the DOS clock. But you'll still hit the Y2K BIOS problem before that... Chris C