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 X-Sender: broeker AT acp3bf To: Kev cc: djgpp AT delorie DOT com Subject: Re: time() frequency In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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.