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