Mail Archives: djgpp/1999/07/26/09:07:29
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...)
- Raw text -