Date: Sun, 7 Sep 1997 13:04:00 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: DJ Delorie <dj AT delorie DOT com>
cc: k3040e4 AT c210 DOT edvz DOT uni-linz DOT ac DOT at, djgpp-workers AT delorie DOT com
Subject: Re: 970831: mktime()
In-Reply-To: <199709032340.TAA16866@delorie.com>
Message-ID: <Pine.SUN.3.91.970907130336.2248D-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Wed, 3 Sep 1997, DJ Delorie wrote:

> If we are going to "fix" this problem, we should fix mktime() itself,
> so that all utilities benefit.  If we aren't going to fix it, then
> we're still OK, but many things break.  If we fix it by adding a new
> function, most programs will blindly use the standard mktime() and
> won't benefit from our work.
> 
> At the moment, I'm inclined to fix mktime so that it quietly does
> something useful in the undefined cases.

I agree, but I suggest to let people have POSIX behavior if they
want.  For example, if POSIXLY_CORRECT environment variable is
defined, avoid the fix and return -1.

Library functions that call `mktime' should be fixed to not fail even
if POSIXLY_CORRECT is defined.  They can unset POSIXLY_CORRECT before
calling `mktime' and restore its setting after that, for example.
Another possibility is to include Markus' safe version in the library
and let library functions call it instead of `mktime'.

Btw, I'm still not sure how did this problem come into existence in
the first place?  If djlsr201.zip is unzipped by InfoZip with the
right TZ setting, won't it change the DOS time stamp so that you never
enter this never-never land?  If so, are we just fixing a problem with
bad unzip programs or incorrect TZ settings here?