Mail Archives: djgpp/1999/07/26/09:07:29

Date: Mon, 26 Jul 1999 16:04:46 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Michal Strelec <strelec AT adam DOT osu DOT cz>
cc: djgpp AT delorie DOT com
Subject: Re: Strange localtime function behaviour
In-Reply-To: <7nh9b2$gcb$>
Message-ID: <Pine.SUN.3.91.990726155255.22556A-100000@is>
MIME-Version: 1.0
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

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 

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

- Raw text -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019