Re: Redhat 7.3 time manipulation bug

Trond Eivind Glomsrød <teg@redhat.com>

From: Trond Eivind Glomsrød <teg@redhat.com>
To: Manuel Sugawara <masm@fciencias.unam.mx>
Cc: Lamar Owen <lamar.owen@wgcr.org>, PostgreSQL Hackers List <pgsql-hackers@postgresql.org>
Date: 2002-05-21T19:09:34Z
Lists: pgsql-hackers
On 21 May 2002, Manuel Sugawara wrote:

> Trond Eivind Glomsrød <teg@redhat.com> writes:
> 
> > Relying on nonstandardized/nondocumented behaviour is a program bug,
> > not a glibc bug.
> 
> The question is: how this thing didn't show up before? ISTM that
> someone is not doing his work correctly.

FWIW, I ran the regressions tests some time ago(probably before that 
change to glibc) . Since the tests are known 
to be broken wrt. time issues anyway (as well as currency, math and sorting), 
it's easy to overlook.

> > PostgreSQL needs fixing.
> 
> Arguably, however, right now is *a lot easier* to fix glibc, and it's
> really needed for production systems using postgreSQL and working on
> RedHat. 

You're not "fixing" glibc, you're reintroducing non-standardized, upstream 
removed behaviour. That's typically a very bad thing. If anything, it 
demonstrates the importance of not using or relying on 
unstandardized/undocumented behaviour (and given that time_t is pretty 
restrictive anyway, you'll need something else to keep dates. It doesn't 
even cover all living people, and definitely not historical dates).

> > Since we ship both, we're looking at it, but glibc is not the
>                       ^^^^^^^^^^^^^^^^^^^
> The sad true is: you only answered when the 'Complain to Red Hat'
> statement appeared, not a single word before and not a single word
> when the bug report were closed. I'm really disappointed.

The bug wasn't open for long, and was closed by someone else.

> The nice thing is: glibc is free software 

Also, notice that this was where the fix came from: The upstream 
maintainers (some of whom work for us, others don't).

-- 
Trond Eivind Glomsrød
Red Hat, Inc.