From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020723 Description of problem: The glibc 2.2.5 shipped with Red Hat 7.3 doesn't seem to be based on the official glibc 2.2.5: An md5 sum of the glibc-2.2.5 tar-ball in the source RPM for glibc-2.2.5-37 doesn't match the official glibc-2.2.5.tar.bz2. This is strange enough by itself, I think. What's worse: The mktime() function's behaviour has changed due to http://bugs.gnu.org/cgi-bin/gnatsweb.pl?debug=&database=default&cmd=view+audit-trail&cmd=view&pr=2738 This results in odd, hard-to-trace bugs in different software packages. PostgreSQL is affected (and the PostgreSQL developers have stated that they will _not_ try to adjust to the new mktime() behaviour), as are PHP applications developed where I work. The glibc developers seem to have changed POSIX interpretation. That may be correct, but the changed behaviour isn't part of the official glibc 2.2.5. I believe that it's a serious mistake to incorporate non-official changes like this into a point-release of Red Hat. Incorporating it into Red Hat 8.0 might be OK (although it will probably still be cursed at by many developers). Please release a new set of glibc packages without the unofficial, changed mktime() behaviour. Otherwise, Red Hat 7.3 will not be compatible with previous Red Hat releases, and it will not be compatible with other Linux distributions. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Example: With php's mktime() function, this will yield different results on Red Hat 7.3 versus older Red Hat releases: 2. print mktime(1,1,1,1,1,1969); Actual Results: On Red Hat 7.3: -1 Expected Results: On older Red Hat releases: -31535939 Additional info:
First of all, relying on undefined behaviour is a bug. The patch in question is going to be in official glibc 2.3 release if you're so attached to "official" changes (glibc in 7.3 has tons of changes from vanilla 2.2.5, not just this one) and as you can see, mktime behaviour was changed to match what other systems are doing. If PHP standard allows years before 1970 (does it allow years before 1902 or after 2038 BTW?), then it is PHP that has to take care about it.
People who need the old behaviour, may grab fixed glibc packages here: http://rpms.arvin.dk/glibc/rh73/