Re: [GENERAL] Psql 7.2.1 Regress tests failed on RedHat7.3 - Mailing list pgsql-hackers

From Thomas Lockhart
Subject Re: [GENERAL] Psql 7.2.1 Regress tests failed on RedHat7.3
Date
Msg-id 3CEA51AB.5B033C42@fourpalms.org
Whole thread Raw
List pgsql-hackers
> > They are just wanting to be standard.  I know this; I just can't say how I
> > know this.  But the link to the ISO definition is
> > http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap04.html#tag_04_14
...
> FWIW, here's what I see in the C99 spec pdf for mktime and the tm
> structure info.  I don't have C90 to compare to and I'm not sure that
> there's anywhere else to look, but....  I assume that the change is
> over whether returning -1 from mktime is a "successful completion" of
> the function.
...
> 3 The mktime function returns the specified calendar time encoded as a
> value of type time_t. If the calendar time cannot be represented, the
> function returns the value (time_t)(-1).

Right. Both standards refer to what is defined, and neither specifies a
behavior for dates and times prior to 1970. "Undefined" means that the
standard chooses to not cover that territory.

In this case, one could fully conform to the standard by returning "-1"
from mktime() on error. That is *all* that the standard asks. One could
also look at tm_isdst to distinguish if this is a real error or whether
it happens to be a time 1 second before 1970-01-01 (-1 on error, 0 for
no DST, 1 for DST, if initialized to -1 before the call).

I'm not sure how to contact the glibc folks in a way which gives full
discussion to this issue. I'm certain that this recent change was done
in good faith but was arbitrary and capricious in formulation and
application. This fundamentally damages the capabilities of Linux-based
systems everywhere and is not in the best interests of anyone or
anything other than its competitors.
                        - Thomas


pgsql-hackers by date:

Previous
From: Thomas Lockhart
Date:
Subject: Re: Redhat 7.3 time manipulation bug
Next
From: Tom Lane
Date:
Subject: Re: Per tuple overhead, cmin, cmax, OID