Redhat 7.3 time manipulation bug
Manuel Sugawara
Something is pretty broken in redhat 7.3 but I'm not sure what and I
don't have time to dig further
masm@test=# select cast('1967-04-18' as timestamptz);
timestamptz
------------------------
1967-04-17 18:00:00-06
(1 row)
masm@test=# select cast(cast('1967-04-18' as date) as timestamp);
ERROR: Unable to convert date to tm
masm@test=#
Both cases works correctly in Redhat 7.2. Sorry if this is not the
correct forum however an alert is nice for people planning an Redhat
upgrade. I hope to see pretty soon an update since I don't want to
downgrade my server.
Regards,
Manuel.
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
Manuel Sugawara
Lamar Owen <lamar...@wgcr.org> writes:
> Where would we go to ferret out the source of this bug? More to the
> point: we need a test case in C that could expose this as a glibc
> bug.
Seems like mktime(3) is having problems with dates before the
epoch. Attached is the a program to test this. The glibc source is now
downloading I will try to hunt down this bug but not until the next
week.
Regards,
Manuel.
--=-=-=
Content-Disposition: attachment; filename=mktime-bug.c
Content-Description: mktime bug test
#include <stdio.h>
#include <time.h>
int main(int argc, char *argv[])
{
struct tm fails;
fails.tm_sec = 0;
fails.tm_min = 0;
fails.tm_hour = 0;
fails.tm_hour = 0;
fails.tm_isdst = -1;
fails.tm_year = 69;
fails.tm_mon = 11;
fails.tm_mday = 30;
if ( mktime(&fails) != -151200L ) {
printf("mktime is broken\n");
return 1;
}
printf("mktime test passed\n");
return 0;
}
--=-=-=
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
--=-=-=--
Lamar Owen
> > Where would we go to ferret out the source of this bug? More to the
> > point: we need a test case in C that could expose this as a glibc
> > bug.
> Seems like mktime(3) is having problems with dates before the
> epoch. Attached is the a program to test this. The glibc source is now
> downloading I will try to hunt down this bug but not until the next
> week.
It's not a bug. At least not according to the ISO C standard. See
http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap04.html#tag_04_14
for the definition of 'Seconds Since the Epoch', then cross-reference to the
man page of mktime.
I don't like it any more than you do, but that is the letter of the standard.
Thomas, any comments?
Our implementation is broken, then. Thomas, is this fixable for a 7.2.x
release, or something for 7.3?
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
Thomas Lockhart
> Our implementation is broken, then. Thomas, is this fixable for a 7.2.x
> release, or something for 7.3?
"Our implementation is broken, then" is really not a conclusion to be
reached. The de facto behavior of mktime() on all world-class
implementations is to support pre-1970 times. This has been true forever
afaik, certainly far longer than PostgreSQL (or Postgres) has been in
existance.
Any standard which chooses to ignore pre-1970 dates is fundamentally
broken imho, and I'm really ticked off that the glibc folks have so
glibly introduced a change of this nature and magnitude without further
discussion.
- Thomas
Lamar Owen
> I see. This behavior is consistent with the fact that mktime is
> supposed to return -1 on error, but then is broken in every other Unix
> implementation that I know.
> Any other workaround than downgrade or install FreeBSD?
Complain to Red Hat. Loudly. However, as this is a glibc change, other
distributors are very likely to fold in this change sooner rather than later.
Try using timestamp without timezone?
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
---------------------------(end of broadcast)---------------------------
Trond Eivind Glomsrød
> Trond Eivind Glomsrød <t...@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.
Lamar Owen
> 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.
The time tests have never broken in this manner before on Red Hat. When the
original regression failure report was posted, I saw right away that this was
not the run of the mill locale issue -- this was a real problem. Regression
testing must become a regularly scheduled activity, methinks. In the RPM
build process, we can control the locale to the extent that the tests will
pass (except on DST days) reliably. I am going to implement this for my next
RPM set. Along with a patch to this problem -- we _can_ patch around this, I
believe, but it's not likely going to be an easy one.
We have gotten blind to the regular locale-induced failures -- this is not a
good thing.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
---------------------------(end of broadcast)---------------------------
Tom Lane
> Relying on nonstandardized/nondocumented behaviour is a program bug, not a
> it, but glibc is not the component with a problem.
A library that can no longer cope with dates before 1970 is NOT my idea
of a component without a problem. We will be looking at ways to get
around glibc's breakage at the application level, since we have little
alternative other than to declare Linux an unsupported platform;
but it's still glibc (and the ISO spec:-() that are broken.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majo...@postgresql.org
Lamar Owen
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
On Tuesday 21 May 2002 06:09 pm, Oliver Elphick wrote:
> On Tue, 2002-05-21 at 18:24, Lamar Owen wrote:
> > 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.
> I'm running glibc 2.2.5 on Debian and all regression tests pass OK (with
> make check). I don't see any note in the glibc Debian changelog about
> reversing an upstream change to mktime().
> I missed the first messages in this thread and I can't find them in the
> archive. What should I be looking for to see if I have the problem you
> have encountered or to see why I don't have it if I ought to have?
Hmmm. Compile and run the attached program. If you get -1, it's the new
behavior. It might be interesting to see the differences here.....
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
--------------Boundary-00=_HMGHHQBFFC8W21ZZMGGD
Content-Type: text/x-csrc; charset="iso-8859-1"; name="mktime-bug.c"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="mktime-bug.c"
#include <stdio.h>
#include <time.h>
int main(int argc, char *argv[])
{
int failout;
struct tm fails;
fails.tm_sec = 0;
fails.tm_min = 0;
fails.tm_hour = 0;
fails.tm_hour = 0;
fails.tm_isdst = -1;
fails.tm_year = 69;
fails.tm_mon = 11;
fails.tm_mday = 30;
failout = mktime(&fails);
printf("The system thinks 11/30/1969 is a timestamp of %d \n", failout);
return 0;
}
--------------Boundary-00=_HMGHHQBFFC8W21ZZMGGD
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
--------------Boundary-00=_HMGHHQBFFC8W21ZZMGGD--
Tom Lane
> +#if 0
> /* Only years after 1970 are defined.
> If year is 69, it might still be representable due to
> timezone differnces. */
> if (year < 69)
> return -1;
> +#endif
Hm. If that fixes it, it implies that all the other support for
pre-1970 dates is still there (notably, entries in the timezone tables).
Should we assume that future glibc releases will rip out the timezone
database entries and other support for pre-1970 dates? Or is the
breakage going to stop with mktime?
Peter Eisentraut
> SuSE already does this. I wonder how they've handled this issue with
> 8.0?
Their glibc doesn't have that problem.
Personally, I think if you need time (zone) support before 1970, obtain
one of the various operating systems that support it. There's little
value in hacking around it in PostgreSQL, since the rest of your system
will be broken as well.
--
Peter Eisentraut pet...@gmx.net
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majo...@postgresql.org)
Thomas Lockhart
> > 8.0?
> Their glibc doesn't have that problem.
My strong recollection is that a SuSE guy was the one applying the
change. So this is coming to those systems too. I may not remember that
correctly though...
> Personally, I think if you need time (zone) support before 1970, obtain
> one of the various operating systems that support it. There's little
> value in hacking around it in PostgreSQL, since the rest of your system
> will be broken as well.
Yes, I'm afraid I agree. In practice, maybe most applications won't
notice. But after getting the Linux time zone databases set up to be
better than most (Solaris has the best I've found for fidelity to
pre-1970 year-to-year conventions) throwing that work away is just plain
silly. I consider this a major gaff on the part of the commercial Linux
houses to not see this coming and to contribute to a better solution.
- Thomas