Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Why is mktime(0,0,0,0,0,0) E_STRICT? »

Why is mktime(0,0,0,0,0,0) E_STRICT?

php.internals

Richard Quadling

19 years ago
With the recent discussion on E_STRICT and the waste of cpu cycles ... Why is mktime(0, 0, 0, 0, 0, 0) generating E_STRICT? What is unstrict about this? Why is important to use time() instead?
-- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!"

Derick Rethans

19 years ago
On Sun, 22 Oct 2006, Richard Quadling wrote:
> With the recent discussion on E_STRICT and the waste of cpu cycles ... > > Why is mktime(0, 0, 0, 0, 0, 0) generating E_STRICT? > > What is unstrict about this? > > Why is important to use time() instead?
It's quicker. regards, Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Lukas Smith

19 years ago
Derick Rethans wrote:
> On Sun, 22 Oct 2006, Richard Quadling wrote: > >> With the recent discussion on E_STRICT and the waste of cpu cycles ... >> >> Why is mktime(0, 0, 0, 0, 0, 0) generating E_STRICT? >> >> What is unstrict about this? >> >> Why is important to use time() instead? > > It's quicker.
as I just said on IRC: i think an e_strict in that place is wrong .. for example the parameters could have been user supplied and you simply check that the parameters are integers if e_strict is our way of telling users about back practices, we should really have a consensus on this list about what constitutes a bad practice. regards, Lukas

Ilia A.

19 years ago
On 22-Oct-06, at 5:48 PM, Lukas Kahwe Smith wrote:
> Derick Rethans wrote: >> On Sun, 22 Oct 2006, Richard Quadling wrote: >>> With the recent discussion on E_STRICT and the waste of cpu >>> cycles ... >>> >>> Why is mktime(0, 0, 0, 0, 0, 0) generating E_STRICT? >>> >>> What is unstrict about this? >>> >>> Why is important to use time() instead? >> It's quicker. > > as I just said on IRC: > i think an e_strict in that place is wrong .. for example the > parameters could have been user supplied and you simply check that > the parameters are integers
That is a weak argument, validation is not just "is the data type correct or not" it should also perform content checks. Not understanding of this basic practice is probably why there are so many insecure PHP applications out-there.
> if e_strict is our way of telling users about back practices, we > should really have a consensus on this list about what constitutes > a bad practice.
You are working under the assumption that mktime(0) and alike will continue working in future versions, that may not end up being the case. Ilia Alshanetsky

Rasmus Lerdorf

19 years ago
Ilia Alshanetsky wrote:
> > On 22-Oct-06, at 5:48 PM, Lukas Kahwe Smith wrote: > >> Derick Rethans wrote: >>> On Sun, 22 Oct 2006, Richard Quadling wrote: >>>> With the recent discussion on E_STRICT and the waste of cpu cycles ... >>>> >>>> Why is mktime(0, 0, 0, 0, 0, 0) generating E_STRICT? >>>> >>>> What is unstrict about this? >>>> >>>> Why is important to use time() instead? >>> It's quicker. >> >> as I just said on IRC: >> i think an e_strict in that place is wrong .. for example the >> parameters could have been user supplied and you simply check that the >> parameters are integers > > That is a weak argument, validation is not just "is the data type > correct or not" it should also perform content checks. Not understanding > of this basic practice is probably why there are so many insecure PHP > applications out-there.
Yes, but E_STRICT is not an argument validation error level. Throwing an E_STRICT here is quite wrong unless we have completely redefined E_STRICT to mean just about any sort of error. mktime($a) is perfectly fine at the language level and E_STRICT is supposed to be language-level errors not something that is thrown based on the value of $a. -Rasmus

Ilia A.

19 years ago
On 22-Oct-06, at 6:27 PM, Rasmus Lerdorf wrote:
> Yes, but E_STRICT is not an argument validation error level. > Throwing an E_STRICT here is quite wrong unless we have completely > redefined E_STRICT to mean just about any sort of error. mktime > ($a) is perfectly fine at the language level and E_STRICT is > supposed to be language-level errors not something that is thrown > based on the value of $a.
As Pierre had correctly identified the E_STRICT currently is only raised in 2 instance mktime() <-- no args or when the deprecated dst parameter is being used. While I agree that E_STRICT maybe misused there, it is only the case if the decision is to maintain the mktime () == time() functionality. Ilia Alshanetsky

Derick Rethans

19 years ago
On Sun, 22 Oct 2006, Ilia Alshanetsky wrote:
> > On 22-Oct-06, at 6:27 PM, Rasmus Lerdorf wrote: > > Yes, but E_STRICT is not an argument validation error level. Throwing an > > E_STRICT here is quite wrong unless we have completely redefined E_STRICT to > > mean just about any sort of error. mktime($a) is perfectly fine at the > > language level and E_STRICT is supposed to be language-level errors not > > something that is thrown based on the value of $a. > > As Pierre had correctly identified the E_STRICT currently is only raised in 2 > instance mktime() <-- no args or when the deprecated dst parameter is being > used. While I agree that E_STRICT maybe misused there, it is only the case if > the decision is to maintain the mktime() == time() functionality.
And I'd be happy to change both to E_DEPRECATED when we get that error level. regards, Derick

Ilia A.

19 years ago
Use of mktime(0) and alike is improper use of the function, more over generally it can be traced to an undesired code behavior. On 22-Oct-06, at 1:45 PM, Richard Quadling wrote:
> With the recent discussion on E_STRICT and the waste of cpu cycles ... > > Why is mktime(0, 0, 0, 0, 0, 0) generating E_STRICT? > > What is unstrict about this? > > Why is important to use time() instead? > > -- > ----- > Richard Quadling > Zend Certified Engineer : http://zend.com/zce.php? > c=ZEND002498&amp;r=213474731 > "Standing on the shoulders of some very clever giants!" > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Ilia Alshanetsky

Pierre Joye

19 years ago
Hello, On 10/23/06, Ilia Alshanetsky <ilia@prohost.org> wrote:
> Use of mktime(0) and alike is improper use of the function, more over > generally it can be traced to an undesired code behavior.
Which is? mktime(0) is just like mktime(24); if it is not the case, there is a bug (it is the case). But I suppose you mean mktime(0,0,0, 0,0,0);? However and for the clarity/sanitiy of this discussion mktime(0,0,0, 0,0,0) does not raise any error, mktime(); does. To solve the only argument in favour of this error message, Derick should simply remove the notice and add these three little line before the arguments parsing: if (ZEND_NUM_ARGS() == 0) { RETURN_LONG((long)time(NULL)); } the slow down is then only an extra C function call. It is an easy solution for possibly annoying change. --Pierre

Pierre Joye

19 years ago
On 10/23/06, Pierre <pierre.php@gmail.com> wrote:
> Hello, > > On 10/23/06, Ilia Alshanetsky <ilia@prohost.org> wrote: > > Use of mktime(0) and alike is improper use of the function, more over > > generally it can be traced to an undesired code behavior. > > Which is? mktime(0) is just like mktime(24); if it is not the case, > there is a bug (it is the case). But I suppose you mean mktime(0,0,0, > 0,0,0);? > > However and for the clarity/sanitiy of this discussion mktime(0,0,0, > 0,0,0) does not raise any error, mktime(); does. > > To solve the only argument in favour of this error message, Derick > should simply remove the notice and add these three little line before > the arguments parsing: > > if (ZEND_NUM_ARGS() == 0) { > RETURN_LONG((long)time(NULL)); > }
To be exact: if (NUM_ARGS()==0 && !gmt) { RETURN_LONG((long)time(NULL)); } as gmmktime uses php_mktime as well, but in GMT mode.

Lukas Smith

19 years ago
Pierre wrote:
> On 10/23/06, Pierre <pierre.php@gmail.com> wrote: >> Hello, >> >> On 10/23/06, Ilia Alshanetsky <ilia@prohost.org> wrote: >> > Use of mktime(0) and alike is improper use of the function, more over >> > generally it can be traced to an undesired code behavior. >> >> Which is? mktime(0) is just like mktime(24); if it is not the case, >> there is a bug (it is the case). But I suppose you mean mktime(0,0,0, >> 0,0,0);? >> >> However and for the clarity/sanitiy of this discussion mktime(0,0,0, >> 0,0,0) does not raise any error, mktime(); does. >> >> To solve the only argument in favour of this error message, Derick >> should simply remove the notice and add these three little line before >> the arguments parsing: >> >> if (ZEND_NUM_ARGS() == 0) { >> RETURN_LONG((long)time(NULL)); >> } > > To be exact: > > if (NUM_ARGS()==0 && !gmt) { RETURN_LONG((long)time(NULL)); } > > as gmmktime uses php_mktime as well, but in GMT mode.
Yes, I see no point in pushing this responsibility into the userland, especially since its a BC break appearently. regards, Lukas

Derick Rethans

19 years ago
On Mon, 23 Oct 2006, Lukas Kahwe Smith wrote:
> Pierre wrote: > > On 10/23/06, Pierre <pierre.php@gmail.com> wrote: > > > Hello, > > > > > > On 10/23/06, Ilia Alshanetsky <ilia@prohost.org> wrote: > > > > Use of mktime(0) and alike is improper use of the function, more over > > > > generally it can be traced to an undesired code behavior. > > > > > > Which is? mktime(0) is just like mktime(24); if it is not the case, > > > there is a bug (it is the case). But I suppose you mean mktime(0,0,0, > > > 0,0,0);? > > > > > > However and for the clarity/sanitiy of this discussion mktime(0,0,0, > > > 0,0,0) does not raise any error, mktime(); does. > > > > > > To solve the only argument in favour of this error message, Derick > > > should simply remove the notice and add these three little line before > > > the arguments parsing: > > > > > > if (ZEND_NUM_ARGS() == 0) { > > > RETURN_LONG((long)time(NULL)); > > > } > > > > To be exact: > > > > if (NUM_ARGS()==0 && !gmt) { RETURN_LONG((long)time(NULL)); } > > > > as gmmktime uses php_mktime as well, but in GMT mode. > > Yes, I see no point in pushing this responsibility into the userland, > especially since its a BC break appearently.
There is no BC break: derick@kossu:~$ php-5.2dev -derror_reporting=16383 -r 'echo mktime(), "\n";' Strict standards: mktime(): You should be using the time() function instead in Command line code on line 1 1161590781 derick@kossu:~$ php-4.4dev -derror_reporting=16383 -r 'echo mktime(), "\n";' 1161590801 regards, Derick

Lukas Smith

19 years ago
Derick Rethans wrote:
> On Mon, 23 Oct 2006, Lukas Kahwe Smith wrote: > >> Pierre wrote: >>> On 10/23/06, Pierre <pierre.php@gmail.com> wrote: >>>> Hello, >>>> >>>> On 10/23/06, Ilia Alshanetsky <ilia@prohost.org> wrote: >>>>> Use of mktime(0) and alike is improper use of the function, more over >>>>> generally it can be traced to an undesired code behavior. >>>> Which is? mktime(0) is just like mktime(24); if it is not the case, >>>> there is a bug (it is the case). But I suppose you mean mktime(0,0,0, >>>> 0,0,0);? >>>> >>>> However and for the clarity/sanitiy of this discussion mktime(0,0,0, >>>> 0,0,0) does not raise any error, mktime(); does. >>>> >>>> To solve the only argument in favour of this error message, Derick >>>> should simply remove the notice and add these three little line before >>>> the arguments parsing: >>>> >>>> if (ZEND_NUM_ARGS() == 0) { >>>> RETURN_LONG((long)time(NULL)); >>>> } >>> To be exact: >>> >>> if (NUM_ARGS()==0 && !gmt) { RETURN_LONG((long)time(NULL)); } >>> >>> as gmmktime uses php_mktime as well, but in GMT mode. >> Yes, I see no point in pushing this responsibility into the userland, >> especially since its a BC break appearently. > > There is no BC break:
I meant, there would be a BC break if this feature gets dropped, which is the point of the message, right? regards, Lukas

Derick Rethans

19 years ago
On Mon, 23 Oct 2006, Lukas Kahwe Smith wrote:
> > > Yes, I see no point in pushing this responsibility into the userland, > > > especially since its a BC break appearently. > > > > There is no BC break: > > I meant, there would be a BC break if this feature gets dropped, which is the > point of the message, right?
Yeah, but there is no point in calling mktime() without arguments as you can use time() doing the same. It's just a friendly hint that you're wasting CPU cycles. It's an E_STRICT message for ****s sake. regards, Derick

Pierre Joye

19 years ago
Hello, On 10/23/06, Derick Rethans <derick@php.net> wrote:
> Yeah, but there is no point in calling mktime() without arguments as you > can use time() doing the same. It's just a friendly hint that you're > wasting CPU cycles. It's an E_STRICT message for ****s sake.
There is no point to keep this message, the fix is easy and does not bring any additional troubles. A lot of applications use mktime() without arguements, I did not read or hear any valid reason to do not fix this issue. --Pierre

Derick Rethans

19 years ago
On Mon, 23 Oct 2006, Pierre wrote:
> On 10/23/06, Derick Rethans <derick@php.net> wrote: > > > Yeah, but there is no point in calling mktime() without arguments as you > > can use time() doing the same. It's just a friendly hint that you're > > wasting CPU cycles. It's an E_STRICT message for ****s sake. > > There is no point to keep this message, the fix is easy and does not > bring any additional troubles. A lot of applications use mktime() > without arguements, I did not read or hear any valid reason to do not > fix this issue.
Stop whining about every code I contribute. It's staying. Derick

Richard Quadling

19 years ago
On 23/10/06, Derick Rethans <derick@php.net> wrote:
> On Mon, 23 Oct 2006, Lukas Kahwe Smith wrote: > > > > > Yes, I see no point in pushing this responsibility into the userland, > > > > especially since its a BC break appearently. > > > > > > There is no BC break: > > > > I meant, there would be a BC break if this feature gets dropped, which is the > > point of the message, right? > > Yeah, but there is no point in calling mktime() without arguments as you > can use time() doing the same. It's just a friendly hint that you're > wasting CPU cycles. It's an E_STRICT message for ****s sake. >
In a simple test, 100000 calls to time() took 0.055 seconds and mktime() took 3.2 seconds. Nearly 60 times faster to use time(). Didn't realise that.
-- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&amp;r=213474731 "Standing on the shoulders of some very clever giants!"

Pierre Joye

19 years ago
Hello, On 10/23/06, Richard Quadling <rquadling@googlemail.com> wrote:
> On 23/10/06, Derick Rethans <derick@php.net> wrote: > > On Mon, 23 Oct 2006, Lukas Kahwe Smith wrote: > > > > > > > Yes, I see no point in pushing this responsibility into the userland, > > > > > especially since its a BC break appearently. > > > > > > > > There is no BC break: > > > > > > I meant, there would be a BC break if this feature gets dropped, which is the > > > point of the message, right? > > > > Yeah, but there is no point in calling mktime() without arguments as you > > can use time() doing the same. It's just a friendly hint that you're > > wasting CPU cycles. It's an E_STRICT message for ****s sake. > > > > In a simple test, 100000 calls to time() took 0.055 seconds and > mktime() took 3.2 seconds. > > Nearly 60 times faster to use time(). > > Didn't realise that.
If you read the other replies to your initial question (which was wrong :), you will realize another thing, this is easily fixable with minimum effort and impact: http://pecl.php.net/~pierre/remove_mktime_strict.txt No visible speed difference . --Pierre

Pierre Joye

19 years ago
Hello, On 10/23/06, Derick Rethans <derick@php.net> wrote:
> On Mon, 23 Oct 2006, Lukas Kahwe Smith wrote: > > > > > Yes, I see no point in pushing this responsibility into the userland, > > > > especially since its a BC break appearently. > > > > > > There is no BC break: > > > > I meant, there would be a BC break if this feature gets dropped, which is the > > point of the message, right? > > Yeah, but there is no point in calling mktime() without arguments as you > can use time() doing the same. It's just a friendly hint that you're > wasting CPU cycles. It's an E_STRICT message for ****s sake.
How can I have "gmmktime();" (which also uses php_mktime) with time()? --PIerre

Derick Rethans

19 years ago
On Mon, 23 Oct 2006, Pierre wrote:
> Hello, > > On 10/23/06, Derick Rethans <derick@php.net> wrote: > > On Mon, 23 Oct 2006, Lukas Kahwe Smith wrote: > > > > > > > Yes, I see no point in pushing this responsibility into the userland, > > > > > especially since its a BC break appearently. > > > > > > > > There is no BC break: > > > > > > I meant, there would be a BC break if this feature gets dropped, which is > > > the > > > point of the message, right? > > > > Yeah, but there is no point in calling mktime() without arguments as you > > can use time() doing the same. It's just a friendly hint that you're > > wasting CPU cycles. It's an E_STRICT message for ****s sake. > > How can I have "gmmktime();" (which also uses php_mktime) with time()?
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: derick@kossu:~$ php-4.4dev -r 'echo mktime(), "\n", gmmktime(), "\n", time(), "\n";' 1161625133 1161632333 1161625133 (it substracts an hour if you are in DST without any valid reason). PHP 5.1+ handles this correctly: derick@kossu:~$ php -r 'echo mktime(), "\n", gmmktime(), "\n", time(), "\n";' 1161625256 1161625256 1161625256 regards, Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org