Re: Redhat 7.3 time manipulation bug - Mailing list pgsql-hackers

On Tuesday 21 May 2002 12:31 pm, Trond Eivind Glomsrød wrote:
> On Tue, 21 May 2002, Lamar Owen wrote:
> > However, as this is a glibc change, other
> > distributors are very likely to fold in this change sooner rather than
> > later.

> Relying on nonstandardized/nondocumented behaviour is a program bug, not a
> glibc bug. PostgreSQL needs fixing. Since we ship both, we're looking at
> it, but glibc is not the component with a problem.

In your opinion.  Not everyone agrees with the new glibc behavior.  In fact, 
some here are rather livid about it.  But that's a digression.  The matter at 
hand is making it work right again.  

It seems to me someone should have thought about this before making the glibc 
change that had the potential for breaking a large application -- regardless 
of who is at fault, it's egg in Red Hat's face for not catching it sooner 
(and egg in my face as well, as I must admit that I of all people should have 
caught this earlier).  

Is the change in glibc behavior noted in the release notes?  The man page 
isn't changed either, from Red Hat 6.2, in fact.  The only change is adhering 
to the ISO definition of 'Seconds Since the Epoch' rather than the defacto 
industry-accepted definition that has been with us a very long time.  

Like PostgreSQL's refusal to upgrade in a sane manner, this should have 
received release notes billing, IMHO.  Then I, nor anyone else, could 
reasonably complain.

But this does show the need for the regression testing packge, no? :-) And it 
also shows the danger in becoming too familiar with certain regression tests 
failing due to locale -- to the extent that a locale issue was the first 
thing thought of.  To the extent that I'm going to change my build process to 
include regression testing as a part of the build -- and any failure will 
abort the build. Maybe that will get my attention.  And anyone else's 
rebuilding from the source RPM.  SuSE already does this.  I wonder how 
they've handled this issue with 8.0? 

In any case, this isn't just a Red Hat problem, as it's going to cause 
problems with the use of timestamps on ANY glibc 2.2.5 dist.  That's more 
than Red Hat, by a large margin.

And I think that it is naive to think that PostgreSQL is the only program that 
has used mktime's behavior in the negative-time_t zone.  Other packages are 
likely impacted, to a greater or lesser extent.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11