Re: [HACKERS] Date/time on glibc2 linux

Hello!

On Thu, 10 Dec 1998, Thomas G. Lockhart wrote:

> > I am sure this is related. When I edited config.h and commented out
> > DATEDEBUG the sources compiled just fine.
> 
> So send my your config.h if you want someone to look at it.
  I've solved this issue. I uncomment it to
#define DATEDEBUG  but forget to add definition. After writing
#define DATEDEBUG 1  postgres compiled.

> > Any use for daylight or tzname or timezone (global vars) produces
> > incorrect results.
> > It looks like glibc2 defines these vars incorrectly. Correct values 
> > are in struct tm (including tmzone and gmtoff).
> > Do you think it is local problem? I am pretty sure it is 
> > "system-wide".
> 
> The glibc2 is a thread-safe library, and I would expect that the *only*
> place with reliable timezone info is in the tm structure. Global
> variables are not to be trusted since they are not available in a
> reentrant way.
  Yes, I understood the idea after you explained this for a first time.

> If the tm structure contains the timezone info (as it claims to on my
> RH5.1 glibc2 system) then for testing try to #undef HAVE_INT_TIMEZONE in
> config.h and see how it goes. If I have a chance tomorrow I'll try doing
> the same at work. I'm guessing that our configure tests look for the
> global variable version first, and that the glibc2 passes that test even
> though the other mechanism is the right one.

#undef HAVE_INT_TIMEZONE in config.h replaced by #define HAVE_INT_TIMEZONE 1
after configure.  On the other hand, os.h (linked to port/linux.h) undefine it. I need to
test that it is still undefined when compiling datetime.c (and dt.c and all
that) - there are all provisions to use tm.tz_name/tm_gmtoff, compiler just
need right defines.

Oleg.
----    Oleg Broytmann  National Research Surgery Centre  http://sun.med.ru/~phd/          Programmers don't die, they
justGOSUB without RETURN.