ID: 50899
User updated by: huchzen-t42 at yahoo dot de
-Reported By: werner at stuerenburg dot com
+Reported By: huchzen-t42 at yahoo dot de
Status: Open
Bug Type: Date/time related
Operating System: SuSE Linux 8.0 (i386)
PHP Version: 5.2.12
New Comment:
In case you need this info - this applies to the currently installed
5.2.11, but 5.2.12 should have been quite similar:
Build Date Oct 6 2009 16:53:48
Configure Command ./configure --prefix=/usr/share
--datadir=/usr/share/php --bindir=/usr/bin --libdir=/usr/share
--includedir=/usr/include --sysconfdir=/etc --with-config-file-path=/etc
--with-exec-dir=/usr/lib/php/bin --disable-debug --enable-bcmath
--enable-calendar --enable-ctype --enable-dbase --enable-exif
--enable-force-cgi-redirect --with-zlib --enable-ftp
--enable-gd-native-ttf --enable-inline-optimization
--enable-magic-quotes --enable-mbstring --enable-shmop --enable-soap
--enable-sigchild --enable-sysvsem --enable-sysvshm --enable-wddx
--enable-zip --with-bz2 --with-curl --with-freetype-dir=yes
--with-gd=yes --with-gdbm --with-gettext --with-gmp --with-iconv
--with-imap=yes --with-imap-ssl=yes --with-jpeg-dir=/usr --with-ldap=yes
--with-mcrypt --with-mhash --with-mssql --with-mysql=/usr --with-mysqli
--with-pdo-mysql=/usr --with-pear=/usr/share/php --with-png-dir=/usr
--with-sqlite --with-ttf --with-libxml-dir=/usr/local/php-5.2
--with-xsl=/usr/local/php-5.2 --with-apxs=/usr/sbin/apxs --with-openssl
--with-tidy i686-ServControl/php5-linux
Server API Apache
Virtual Directory Support disabled
Configuration File (php.ini) Path /etc
Loaded Configuration File /etc/php.ini
Scan this dir for additional .ini files (none)
additional .ini files parsed (none)
PHP API 20041225
PHP Extension 20060613
Zend Extension 220060519
Debug Build no
Thread Safety disabled
Zend Memory Manager enabled
IPv6 Support enabled
Registered PHP Streams https, ftps, compress.zlib, compress.bzip2,
php, file, data, http, ftp, zip
Registered Stream Socket Transports tcp, udp, unix, udg, ssl, sslv3,
sslv2, tls
Registered Stream Filters zlib.*, bzip2.*, convert.iconv.*,
string.rot13, string.toupper, string.tolower, string.strip_tags,
convert.*, consumed
Previous Comments:
------------------------------------------------------------------------
[2010-02-02 10:00:36] werner at stuerenburg dot com
(_exactly_ is that OS running) : I told you initially already, it is
one of the required fields in the form: SuSE Linux 8.0 (i386)
pz1:~# uname -a
Linux 2.4.37-servcontrol-smp-bigmem #1 SMP Wed Feb 25 16:59:45 CET 2009
i686 unknown
And yes, we use PHP as an Apache-module in case you didn't guess it.
------------------------------------------------------------------------
[2010-02-02 08:41:59] j...@php.net
You get it with some other SAPI then, which might that be? And what
_exactly_ is that OS running it (uname -a)? Webserver? (not enough info
means this is quite bogus quite soon..)
------------------------------------------------------------------------
[2010-02-01 20:51:59] werner at stuerenburg dot com
Sorry, can't reproduce anymore as we degraded to 5.2.11 on the
production machine (on my development box, I'm still on 5.2.6).
Actually I didn't do
echo date('Y');
but instead
echo date('d.m.Y');
which should not matter. (Note that my provider reported that the
cgi-version does not produce this error!)
As Google reports, other people had this kind of error as well, notably
with WordPress (most probably anywhere where the date function is
used).
I myself noticed the problem first from the setcookie-error mentioned
initially.
I tracked down the problem to the date-function, googled, found the
indication that this is related to 5.2.12 and called my provider who was
working on this problem already. He was glad that I found that this
error was sufficiently documented; he contemplated to hack date.c in
5.2.12, but after some discussion, we decided to switch back.
Also, I received emails triggered by a database-related error from my
blog; a search engine was spidering and used perfectly valid addresses
which the database could not find an entry to whence the error mail.
I didn't investigate this, but I guess that the query used some kind of
date-condition which produced an empty result. After we switched back to
5.2.11, this error was gone as well.
------------------------------------------------------------------------
[2010-02-01 18:02:26] der...@php.net
This works fine here, can you provide:
- a short reproducing script?
- output of "uname -a"
------------------------------------------------------------------------
[2010-02-01 16:52:29] werner at stuerenburg dot com
I just want to inform you about the dialog with my provider in case
anybody is interested (in German):
> > > Ich habe einen Bug-Report erstellt:
> > >
> > > http://bugs.php.net/bug.php?id=50899
> >
> > Vielen Dank dafür! Sie sehen ja die Reaktion:
> >
> > "Seems to be fixed in SVN."
> >
> > So wird also ein so gravierender Fehler von den Entwicklern
abgetan. Was soll
> > man da noch erwarten?
> Tja, die Wut der Anwender wird über sie kommen...
Mittlerweile wissen unsere Kunden welche "Qualität" PHP-Releases haben,
womit
sich die Wut erfreulicherweise in Grenzen hält.
> Hier ist aber der Fehler ja anerkannt worden; dass die jetzt nicht
> eine Eil-Mail rausschicken und die aktuelle Version reparieren, ist
> schon ein Unding. Dieser Fehler hat ja weitreichende Konsequenzen;
so
> kann man sich seine Reputation schnell kaputtmachen. Wer weiß,
welche
> Nase an dieser Schaltstelle sass. (Der Chef weiss davon natürlich
> nichts...)
Welcher Chef? Das ist ja das Problem. Die haben keinen Chef und jeder
murkst
da vor sich hin wie er lustig ist und Einrichtungen wie
http://qa.php.net/
scheinen nicht mal die Webseite wert zu sein, die für das Projekt ins
Leben
gerufen wurde.
Denn wenn so ein offensichtlicher Fehler durch eine Qualitätskontrolle
geht,
kann diese ja wohl nicht viel taugen, wenn sie nicht mal merkt, dass
die
elementare Datumsfunktion des gesamten Interpreters fehlerhaft
funktioniert.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/50899
--
Edit this bug report at http://bugs.php.net/?id=50899&edit=1
