Date: Sun, 7 Sep 1997 19:08:17 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: DJ Delorie <dj AT delorie DOT com>
cc: djgpp-workers AT delorie DOT com
Subject: Re: 970831: mktime()
In-Reply-To: <199709071433.KAA20856@delorie.com>
Message-ID: <Pine.SUN.3.91.970907190603.2962C-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Sun, 7 Sep 1997, DJ Delorie wrote:

> POSIX doesn't define mktime() behavior.  ANSI does.  All it states is
> that it returns -1 if the calendar time can't be represented as a
> time_t.  Times within the DST overlap *can* be represented, but the
> results are undefined, since there are two valid solutions.  I'm
> simply proposing that we choose one, rather than returning -1.

OK, then I agree.

> The case where this comes up is when you stat() a file that was
> created during the overlap (i.e. converting DOS's ymd.hms to time_t)
> or when you call time() during the overlap, and DOS doesn't tell you
> whether it's standard or daylight time.  In both cases, we're
> converting a valid date/time from DOS into a time_t, but we don't know
> which of the two time_t values are correct because DOS doesn't tell us
> if daylight savings time is in effect for that date/time.

When the zip file was unpacked, shouldn't UnZip set its DOS time stamp so 
that this never happens (assuming TZ is set)?  The timezone file should 
tell whether DST is in effect or not, no?