php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #50899 date('Y') returns 8632884266970 instead of 2010
Submitted: 2010-02-01 13:18 UTC Modified: 2010-02-03 21:54 UTC
Votes:2
Avg. Score:5.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:2 (100.0%)
Same OS:0 (0.0%)
From: huchzen-t42 at yahoo dot de Assigned:
Status: Not a bug Package: Date/time related
PHP Version: 5.2.12 OS: SuSE Linux 8.0 (i386)
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: huchzen-t42 at yahoo dot de
New email:
PHP Version: OS:

 

 [2010-02-01 13:18 UTC] huchzen-t42 at yahoo dot de
Description:
------------
See for example http://wordpress.org/support/topic/358394
or http://www.google.de/search?q="8632884266970"

This bug implies other errors, for example "Expiry date cannot have a year greater then 9999" from setcookie as setcookie has to transfer the timestamp into a date format.

Workaround: Restore version 5.2.11

My provider asserts that this error does not ally to the cgi-version.

Reproduce code:
---------------
echo date('Y);

Expected result:
----------------
2010

Actual result:
--------------
8632884266970 

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-02-01 13:19 UTC] werner at stuerenburg dot com
sorry: should read "apply "

My provider asserts that this error does not apply to the cgi-version.
 [2010-02-01 13:21 UTC] jani@php.net
Seems to be fixed in SVN.
 [2010-02-01 13:22 UTC] jani@php.net
Please try using this snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/


 [2010-02-01 16:52 UTC] 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.
 [2010-02-01 18:02 UTC] derick@php.net
This works fine here, can you provide:
- a short reproducing script?
- output of "uname -a"
 [2010-02-01 20:51 UTC] 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-02 08:41 UTC] jani@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-02 10:00 UTC] 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 11:59 UTC] huchzen-t42 at yahoo dot de
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
 [2010-02-02 17:59 UTC] jani@php.net
You assume quite a lot. "should have been" and such don't sound very convincing and I'm starting to think you failed somehow with the installation. Did you try the snapshot or not?
 [2010-02-03 21:54 UTC] jani@php.net
See bug #50930
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 06:01:29 2024 UTC