Date: Mon, 26 Jul 1999 16:04:46 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Michal Strelec cc: djgpp AT delorie DOT com Subject: Re: Strange localtime function behaviour In-Reply-To: <7nh9b2$gcb$1@ns.felk.cvut.cz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Mon, 26 Jul 1999, Michal Strelec wrote: > Here it is. This program works Good. But when I have ommited the line with > setting cas.tm_isdst=0; > Conversion makes sometimes strange time+dates. If you want localtime to compute the tm_isdst member for you (which is usually the only reasonable thing to do, since a human cannot easily know when the DST setting is in effect), you need to set tm_isdst to -1. Then, on return from the function, tm_isdst will be set to either zero (meaning no DST) or positive, as appropriate for the current time zone. If you *do* know whether DST is in effect on 27/7/1999, then set tm_isdst to either zero (no DST) or 1 (DST), and localtime should then work accordingly. Leaving tm_isdst unassigned effectively passes some random garbled value to localtime, thus you get random garbage in return. > I have tried this example in BC3.1 and there works everything fine. (even > without setting cas.isdst=0) BC doesn't support the different timezones as extensively as DJGPP does, it usually works with a default time zone (EST5EDT, if memory serves). So it doesn't come anywhere near the complexity of time-related computations that our library does, thus it is much less vulnerable to garbled input. (I wonder why people always bring up Borland as an example that DJGPP should follow? It has much less functionality and much more bugs...)