# Why is mktime(0,0,0,0,0,0) E_STRICT? - Thread: https://externals.io/message/26152 - Original archive: https://news-web.php.net/php.internals/26152 - Started by Richard Quadling on 2006-10-22T17:45:11+00:00 - Messages: 30 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/26152.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #26152 — Richard Quadling — 2006-10-22T17:45:11+00:00 URL: https://externals.io/message/26152#26152 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!" --- ## #26155 — Derick Rethans — 2006-10-22T21:16:11+00:00 URL: https://externals.io/message/26152#26155 · In reply to: #26152 > 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 --- ## #26156 — Lukas Kahwe Smith — 2006-10-22T21:48:43+00:00 URL: https://externals.io/message/26152#26156 · In reply to: #26155 Derick Rethans wrote: > > > > […] > > 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 --- ## #26158 — Ilia Alshanetsky — 2006-10-22T22:05:15+00:00 URL: https://externals.io/message/26152#26158 · In reply to: #26152 Use of mktime(0) and alike is improper use of the function, more over generally it can be traced to an undesired code behavior. > 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!" > > -- > > > > Ilia Alshanetsky --- ## #26159 — Ilia Alshanetsky — 2006-10-22T22:08:29+00:00 URL: https://externals.io/message/26152#26159 · In reply to: #26156 > Derick Rethans wrote: > > […] > > 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 --- ## #26160 — Rasmus Lerdorf — 2006-10-22T22:27:41+00:00 URL: https://externals.io/message/26152#26160 · In reply to: #26159 Ilia Alshanetsky wrote: > > > > > […] > > 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 --- ## #26161 — Pierre — 2006-10-22T22:29:05+00:00 URL: https://externals.io/message/26152#26161 · In reply to: #26158 Hello, > 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 --- ## #26163 — Ilia Alshanetsky — 2006-10-22T22:44:12+00:00 URL: https://externals.io/message/26152#26163 · In reply to: #26160 > 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 --- ## #26162 — Pierre — 2006-10-22T22:49:25+00:00 URL: https://externals.io/message/26152#26162 · In reply to: #26161 > Hello, > > > > […] > > 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. --- ## #26166 — Derick Rethans — 2006-10-23T06:56:18+00:00 URL: https://externals.io/message/26152#26166 · In reply to: #26163 > > > > […] > > 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 --- ## #26167 — Lukas Kahwe Smith — 2006-10-23T07:46:58+00:00 URL: https://externals.io/message/26152#26167 · In reply to: #26162 Pierre wrote: > > > […] > > 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 --- ## #26168 — Derick Rethans — 2006-10-23T08:09:48+00:00 URL: https://externals.io/message/26152#26168 · In reply to: #26167 > Pierre 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: 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 --- ## #26169 — Lukas Kahwe Smith — 2006-10-23T08:15:06+00:00 URL: https://externals.io/message/26152#26169 · In reply to: #26168 Derick Rethans wrote: > > > > […] > > 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 --- ## #26170 — Derick Rethans — 2006-10-23T08:19:11+00:00 URL: https://externals.io/message/26152#26170 · In reply to: #26169 > > […] > > 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 --- ## #26175 — Pierre — 2006-10-23T10:22:36+00:00 URL: https://externals.io/message/26152#26175 · In reply to: #26170 Hello, > 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 --- ## #26177 — Richard Quadling — 2006-10-23T10:35:03+00:00 URL: https://externals.io/message/26152#26177 · In reply to: #26170 > > > > […] > > 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&r=213474731 "Standing on the shoulders of some very clever giants!" --- ## #26176 — Pierre — 2006-10-23T10:41:25+00:00 URL: https://externals.io/message/26152#26176 · In reply to: #26177 Hello, > > > […] > > 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 --- ## #26178 — Pierre — 2006-10-23T10:46:11+00:00 URL: https://externals.io/message/26152#26178 · In reply to: #26170 Hello, > > > > […] > > 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 --- ## #26179 — Derick Rethans — 2006-10-23T10:48:58+00:00 URL: https://externals.io/message/26152#26179 · In reply to: #26175 > > > > […] > > 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 --- ## #26180 — Pierre — 2006-10-23T10:58:26+00:00 URL: https://externals.io/message/26152#26180 · In reply to: #26179 Hello, > > > > […] > > Stop whining about every code I contribute. It's staying. Excuse me, can you explain what you mean? I explain you how the code you wrote works and how easy it is to fix it. A simple search clearly shows that a lot of applications use these two functions without arguments and you keep ignore this fact. Anyway, Derick's law applies again here. I really don't care, I only tried to provide a valid explanation and solution to a valid problem. Things that you, maintainer of this extension, is not able to provide. --Pierre --- ## #26181 — Richard Quadling — 2006-10-23T11:13:38+00:00 URL: https://externals.io/message/26152#26181 · In reply to: #26176 > Hello, > > > > […] > > 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 > Yes. I was wrong. Sorry. And a perfect fix. Now `mktime()` is an alias for `time()`, except when additional parameters are supplied. -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" --- ## #26183 — Ilia Alshanetsky — 2006-10-23T15:20:47+00:00 URL: https://externals.io/message/26152#26183 · In reply to: #26176 > 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 I see no reason to make `mktime()` an alias of `time()`, you are basically advocating misuse of functions. Yes there are over 2,000 results on google showing people calling `mktime()`, but I bet there are even more register_globals users and yet we've all decided to remove it in PHP6. Ilia Alshanetsky --- ## #26185 — Pierre — 2006-10-23T15:26:48+00:00 URL: https://externals.io/message/26152#26185 · In reply to: #26183 Hello, > > > > […] > > I see no reason to make `mktime()` an alias of `time()`, you are > basically advocating misuse of functions. Yes there are over 2,000 > results on google showing people calling `mktime()`, but I bet there > are even more register_globals users and yet we've all decided to > remove it in PHP6. Ilia, it is not about making an alias. It is about restoring a widely use behavior in mktime and about making gmktime useable. This change is nothing but a unilateral break (even in E_STRICT). --- ## #26186 — Ilia Alshanetsky — 2006-10-23T15:37:05+00:00 URL: https://externals.io/message/26152#26186 · In reply to: #26185 Unilateral break? lol... Actually it is no break at all, take PHP4 code move it to PHP and you won't even see the warning because `E_STRICT` is not even shown by default. > Hello, > > > > […] > > Ilia, it is not about making an alias. It is about restoring a widely > use behavior in mktime and about making gmktime useable. This change > is nothing but a unilateral break (even in E_STRICT). > > -- > > > > Ilia Alshanetsky --- ## #26187 — Lukas Kahwe Smith — 2006-10-23T15:39:07+00:00 URL: https://externals.io/message/26152#26187 · In reply to: #26186 Ilia Alshanetsky wrote: > Actually it is no break at all, take PHP4 code move it to PHP and you > won't even see the warning because `E_STRICT` is not even shown by default. haha regards, Lukas --- Next page: https://externals.io/message/26152.md?page=2