Mail Archives: djgpp/1994/08/23/07:40:58
I haven't seen any response to this on the list, so I thought I'd share
my experiences with you all:
roe2 AT midway DOT uchicago DOT edu writes, in a message from Aug. 15th:
> I've just been investigating djgpp's handling of timezone information,
> and basically (forgive my bluntness) it's just plain wrong.
[...]
> stat() simply assumes everybody lies four hours west of GMT. The use
> of the TZ variable and the tzset() (initialization) function had
> absolutely no effect on the time returned by stat(). Bug #1.
Confirmed. stat() is definitely broken here.
> The second path, and the one chosen by whoever did the djgpp port of
> UnZip, is to use the Berkeley ftime() function. This, at least, is
> vaguely in the ballpark
I have found that time(), ftime(), localtime() and gmtime() behave correct-
ly ONLY if you set up TZ as per Posix standard. For my timezone, that would
mean:
TZ=MET-1METDST-2,M3.5.0/02:00,M9.5.0/02:00
which is not quite intuitive. ftime() does not return the correct information
about timezone offsets/daylight savings time usage, though.
> djgpp 1.12 using ftime():
> with no TZ variable: timezone adds 5 hours; DST adds zero ok...
> with TZ=PST8: timezone adds 8 hours; DST adds zero good
> with TZ=PST8PDT: timezone adds zero; DST adds zero WRONG
I traced through the tzset() function in the library sources. Pretty com-
plicated stuff. It seems that just specifying the ...PDT part without
giving the specific times that DST takes effect is not handled correctly;
tzload() - an internal function in the ctime.c library module - bails
out and acts as if NO TZ setting is in effect.
--
Henrik Storner | "Man is the best computer we can put aboard a space-
(storner AT olicom DOT dk) | craft ... and the only one that can be mass produced
System Engineering | with unskilled labor."
Olicom Denmark | Wernher von Braun
- Raw text -