Re: Redhat 7.3 time manipulation bug

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