Date:	Sun, 7 Sep 1997 10:33:13 -0400 (EDT)
Message-Id:	<199709071433.KAA20856@delorie.com>
From:	DJ Delorie <dj AT delorie DOT com>
To:	eliz AT is DOT elta DOT co DOT il
CC:	djgpp-workers AT delorie DOT com
In-reply-to:	<Pine.SUN.3.91.970907130336.2248D-100000@is> (message from Eli
	Zaretskii on Sun, 7 Sep 1997 13:04:00 +0300 (IDT))
Subject:	Re: 970831: mktime()

> > 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.

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.

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.

My solution is that we always assume that the zone we're switching
*to* is in affect (or the one we're switching *from*, if the zone
switches in the PM instead of the AM, so that we never cross a date
boundary with our hour math).

- Raw text -