X-Authentication-Warning:	acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date:	Tue, 16 Nov 1999 12:56:47 +0100 (MET)
From:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
X-Sender:	broeker AT acp3bf
To:	Kev <co273 AT freenet DOT buffalo DOT edu>
cc:	djgpp AT delorie DOT com
Subject:	Re: time() frequency
In-Reply-To:	<Pine.GSO.3.96.991115233743.22152A-100000@freenet.buffalo.edu>
Message-ID:	<Pine.LNX.3.93.991116125150.24782C-100000@acp3bf>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Mon, 15 Nov 1999, Kev wrote:

> Yeek!  And the scary thing is that the guy I'm having this shouting match
> with uses Borland C++5, which might use the Microsecond Time convention!

Possible, but somewhat unlikely. Last I looked, Borland tried to stick to
standards, wherever sensible. And there in fact *is* a standard that
mandates time_t counting in seconds. It's the POSIX standard used on
practically all of today's Unix boxes. 

> And If I take this code to a SPARC or a Linux box, It'll yield different
> results.

Not really. Those are somewhat bound by POSIX compliance, so they *will*
use time_t as 'seconds since 1/1/1970, 00:00h GMT'. 

> Oy Vey...I need a drink. This portability problem is making me puke.

The trick is not to induce portability problems of this type, in the first
place. Do *not* assume you know what a time_t is. You don't really have to
know, anyway, so there's no need to risk portability. Think of time_t as
some kind of 'magic cookie': you get it from time(), and you can pass it
to other functions, which do know how to unwind the magic. Don't try
coding yourself what the ANSI C Standard made the C Library writers
implement, already.
 
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -