Hello Pierre, shouldn't we use E_NOTICE here? obviously there is something wrongwith those calls and other functions that check their input typically raise them as E_NOTICE or E_WARNING. In this case I personally would prefer E_NOTICE and think E_STRICT is wrong. If we had E_DEPRECATED we could argue. When really dropping supportfor these values/calls they would lead to an E_ERROR in later versions so E_DEPRECATED now would be correct. Since we don't have E_DEPRECATEDright now and E_STRICT is used for deprecated stuff as well it makes sense. But i alsoagree with Rasmus that this is a domain error, thus E_NOTICE seems to be the right way after all.
All in all and that is the main reason i am replying is that at least to me this is another proof that we need E_DEPRECATED rather now (as in 5.2.0) than later. best regards marcus p.s.: I am neither disagreeing nor agreeing with you in particular here Pierre, your mail is just the last one i read in this thread... Monday, October 23, 2006, 8:00:13 PM, you wrote: > Hello, > On 10/23/06, Derick Rethans <[EMAIL PROTECTED]> wrote: >> gmmktime() without parameters is broken in PHP 4 anyway. If you don't >> give it arguments than it should default to the current date >> and hour (in GMT for gmmktime() and in localtime for >> mktime()). In both places this should result in the same timestamp, >> which gmmktime() doesn't even do on PHP 4: > Our point is to do not raise any warning in these two functions when > they are called without arguments. Misunderstanding of the GMT idea by > the previous implementation is another topic. > I do not understand why it is a problem to add three lines to > php_mktime and forget about it rather than adding more pain to the > e_strict stack. > You like to use only time()? fine, but we still have no way to use > "gmmktime();" without warning and we are forced to change our mktime() > calls, for no reason. > --Pierre Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
