Date:	Sun, 13 Oct 2002 08:25:04 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
cc:	djgpp AT delorie DOT com
Subject:	Re: profiling with DJGPP
In-Reply-To:	<10210130615.AA18852@clio.rice.edu>
Message-ID:	<Pine.SUN.3.91.1021013081525.11821I-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Sun, 13 Oct 2002, Charles Sandmann wrote:

> > I think the _real_ fix is to set TZ.  There are no good reasons why not.
> 
> There is one excellent reason not to set TZ - you ship an image which 
> is run outside the DJGPP environment (standalone).

TZ can be set to a SysV-style string that defines the dates of standard 
to daylight-saving time transition.  This alternative doesn't need any 
files.  Problem solved.

> These shouldn't run
> significantly slower just because an environment variable is not set.

The slow-down is typical only for Unix programs that use gettimeofday.  
gettimeofday is a system call on Unix, so it's fast, whereas on 
DOS/Windows we need to do the timezone stuff (because the system clock 
works in local time, not UTC).  However, Unix programs assume TZ is set.  
So I don't expect any real-life situations with stand-alone programs like 
the one you thought about, because such a program won't call time-related 
functions in their inner loops.

> If TZ wasn't set before, and the environment wasn't
> changed, calling getenv() over and over again doesn't make any sense.

I don't disagree, but the change we should try is different from what you 
suggested.  tzsetwall already does TRT when lcl_is_set is -1 (by simply 
returning); the only thing we should change is that getenv need not be 
called if the environment didn't change.

- Raw text -