www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1998/01/28/11:16:10

From: Chris Croughton <crough45 AT amc DOT de>
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
Lines: 26
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019