Re: date() behaviour changed in 5.1?

From: Date: Tue, 15 Nov 2005 16:59:32 +0000
Subject: Re: date() behaviour changed in 5.1?
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-20008@lists.php.net to get a copy of this message
    If you pass bad data to a function, it should not warn you?
    I'd rather have it as a FATAL error. :)
    Nothing to fix here, move along. (and fix your code..)
    --Jani
On Tue, 15 Nov 2005, Sean Coates wrote:
I discussed this with Rasmus and Derick, yesterday, but I don't think we came to a conclusion.. Is this a bug, or intended behaviour? sean@iconoclast:~$ /opt/src/php-5.0.4/sapi/cli/php -r 'echo date("r", "1132003418 ") ."\n";' Mon, 14 Nov 2005 16:23:38 -0500 sean@iconoclast:~$ /opt/src/php5-200511131530/sapi/cli/php -r 'echo date("r", "1132003418 ") ."\n";' Warning: date() expects parameter 2 to be long, string given in Command line code on line 1 sean@iconoclast:~$ The conclusion SEEMED to be that it's a bug in the parameter parsing API (as date() now uses the new API). I think that the 2nd param should automatically be cast to an int. Yes, I realize that the documentation says it should be an int, and I'm ok with that (the extraneous whitespace is my fault). I think it should be mentioned in the release docs if it won't be fixed, though. Also, a warning is pretty harsh. A E_NOTICE is more representative of what's happening. Also, in the E_WARNING scenario above, date() no longer returns the expected result (based on <=5.0 code). So: is this a bug? If so, I can send a report -- I just didn't want it to get bogussed without discussion. If not -- I really think this should be fixed before 5.1.. I realize it's very late in the game, though. Opinions? S


« previous php.internals (#20008) next »