Re: [GENERAL] Psql 7.2.1 Regress tests failed on RedHat 7.3 - Mailing list pgsql-hackers

On Tuesday 21 May 2002 09:23 am, Thomas Lockhart wrote:
> > While I don't agree with the standard, trying to be standard isn't really
> > a 'problem'.  Relying on a side-effect of a nonstandard call is the
> > problem.

> In my mind no one associated with glibc gets high marks for anything
> having to do with this change. It is unbelievably short sighted.

Oh, I most certainly agree with you on this Thomas.  The glibc people are just 
being adamant about it being 'standard.'  And I certainly didn't mean to step 
on your toes, either -- as I can tell this is a sore point for you.  I'm just 
trying to see what, if anything, we can do about it.

> > Can we pull in the BSD C library's mktime()?  OR otherwise utilize it to
> > fit this bill?

> Maybe, but probably forcing a *really* annoying code fork or patch to
> get the entry points to play nice with glibc. We'll also need to figure
> out how to manage the time zone database and how to keep it in sync.

> This is a seriously big problem, and we'll need to research what to do
> next. One possibility is to strip out all string time zone behavior and
> support only the SQL date/time standard, which specifies only numeric
> offsets and ignores real-world time zone usage and behaviors. Hmm, IBM
> contributed to that standard too, maybe the common thread is not a
> coincidence.

Well, the existing behavior, according to my first read of the code, is to 
assume UTC if the time_t is predicted to be out of range.  There is a macro 
for this, I see.  And the problem is that the out-of-range condition is 
happening at a different place.  I don't like this thought, but the most 
consistent, least-common-denominator tack would to be flag anything prior to 
epoch as out-of-range, even if the underlying calls can handle negative 
time_t.  I don't like that one whit.  But I like inconsistent data even less.

> The new glibc behavior is really disappointing. Help and ideas are
> appreciated; reimplementing an entire date/time system may be a lot of
> work.

Well, it was good foresight on your part to put all the mktime stuff in the 
one place.  I'm going to go through it and see if I understand what I'm 
looking at first.

But I see a couple of possibilities that we can control:
1.)    Have configure test for broken mktime and sub our own mktime in that case 
(if this is even possible -- while the various BSD's have mktime and friends, 
how difficult is it going to be to unshackle that from a BSD kernel 
underneath -- I've not looked at the code for OpenBSD's mktime (which I have 
on hand), but I guess I will take a look now);
2.)    Rewrite our stuff to not depend on any mktime, and thus be more portable 
(perhaps?).

But, in any case, I didn't mean to step on your toes by any of my comments; I 
completely agree with you that glibc and the ISO C standard cited are daft in 
this.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11