ZF-7185: getdate() expects parameter 1 to be long, string given

Issue Type: Bug Created: 2009-07-02T10:29:10.000+0000 Last Updated: 2009-07-29T04:59:11.000+0000 Status: Resolved Fix version(s): - 1.9.1 (11/Aug/09)

Reporter: Marcel Kloubert (generalpd) Assignee: Thomas Weidner (thomas) Tags: - Zend_Date

Related issues: - ZF-7188



I am defining an own error handler and catching anything. Also function calls like @getdate() are catched there.

The problem is that I get a message like that:

getdate() expects parameter 1 to be long, string given

FILE: /xyz/classes/Zend/Date/DateObject.php
LINE: 667

I solved the problem by changing the line 667 to the following one:

return @getdate((int)$timestamp);


Posted by Thomas Weidner (thomas) on 2009-07-02T10:49:49.000+0000

So you propose to limit Zend_Date to dates from 1914 to 2034 because you use a own error handler ?

Posted by Dolf Schimmel (Freeaqingme) (freak) on 2009-07-02T10:56:32.000+0000

I would suggest you stop catching anything, but only catch errors/exceptions.

Furthermore I was not able to reproduce this issue, propose to close it as cannot reproduce, or just 'not an issue'..

Posted by Thomas Weidner (thomas) on 2009-07-02T11:08:55.000+0000

Closing as non-issue

Posted by Marcel Kloubert (generalpd) on 2009-07-02T11:38:15.000+0000

@Dolf Schimmel: I need the complete error output for my debugger.

If you look at the code starting at line 666:

    // 32bit timestamp
    if (abs($timestamp) <= 0x7FFFFFFF) {
        return @getdate($timestamp);

The IF-block is only called if the value of abs($timestamp) is smaller or equal 2^31 - 1, that means, that values that are greater, are handled by the following lines. So I think it might be better (and no problem) to cast the $timestamp variable to integer to produce no E_WARNINGs. I don't think that a cast like that creates limitations.

Posted by Florent PELLET (f.pellet) on 2009-07-06T01:17:50.000+0000

I don't know how to reopen issue, I copy ZF-7188 here, hoping that my remarks will be seen.

By looking better, the problem is that getUnixTimestamp() (class DateObject) send an empty string when this-> _ unixTimestamp equals null, while getdate() waits null value and not empty string.

A correction which I propose is simple. It is enough to add a line in getUnixTimestamp() , which becomes:

<pre class="highlight">
    protected function getUnixTimestamp()
        if($this->_unixTimestamp === null) return null;

        if ($this->_unixTimestamp === intval($this->_unixTimestamp)) {
            return (int) $this->_unixTimestamp;
        } else {
            return (string) $this->_unixTimestamp;

Posted by Thomas Weidner (thomas) on 2009-07-06T02:55:50.000+0000

I still don't see a issue.

When the timestamp is not a number it will call "getdate()" which itself will NEVER raise an exception as it accepts to be called without a parameter.

Line 661 prevents that non numeric values are given to the code below this line. Line 666 will in the case you described never be called.

Posted by Marcel Kloubert (generalpd) on 2009-07-06T04:26:09.000+0000

I know, but the expression "abs($timestamp)" converts the variabel "$timestamp" to an integer automatically, but the data type of the variable is never changed (if the datatype of $timestamp is string, it keeps at being a string).

It seems so that in some cases the $timestamp is a >>>numeric<<< STRING, so the getdate() function of PHP creates an E_WARNING if the data type of the $timestamp variabel is NOT of the type long.

I don't think that it is much work to do an explicit cast ... in other words: to write "@getdate((int)$timestamp)" instead of "@getdate($timestamp)"

I am using PHP 5.2.6 (LAMP)

Posted by Thomas Weidner (thomas) on 2009-07-06T05:21:55.000+0000

There is only one way how this could happen...

When you call Zend_Date->getDate() manually by giving a string within unix rage. And this case MUST throw an error/warning as it's then expected behaviour.

For Zend_Date the handling is like this: Initiation -> timestamp = null -> getDate() called at line 662 Integer given -> Timestamp in unix timestamp range -> getDate($timestamp) called at line 667 String given -> Timestamp extends unix range -> code below 669 is called.

And a empty string, like mentioned above, will not pass the isNumeric check at line 661.

Posted by Marcel Kloubert (generalpd) on 2009-07-06T07:39:03.000+0000

dann halt nicht ... grummel

Posted by Thomas Weidner (thomas) on 2009-07-06T08:33:12.000+0000

Please stay at a language which all readers are conform with.

As you referred to line 667, what does the line 661 read ? It should be "if (!is_numeric($timestamp)) {"

I expect that it's different in your case which would be the reason why you have a different behaviour. As I said: Empty strings or null would not pass the numeric check and unix timestamps MUST be integers otherwise we would have multiple other problems.

Posted by Marcel Kloubert (generalpd) on 2009-07-06T16:48:33.000+0000

@Thomas Weidner: Mal eine Frage: Wo kann man sein Benutzerkonto löschen? Ich finde nichts im Bereich 'Profile' ... :-(

Posted by Florent PELLET (f.pellet) on 2009-07-07T00:54:39.000+0000

@Thomas Weidner

I don't call "getdate()" manually.

A warning is sent on this line: New Zend_Date ('2009-07-01 00:00:00'); a DateTime in MySql 5.1

Posted by Dolf Schimmel (Freeaqingme) (freak) on 2009-07-07T01:00:02.000+0000

"Zend recommends the most current release of PHP for critical security and performance enhancements, and currently supports PHP 5.2.4 or later."

Posted by Florent PELLET (f.pellet) on 2009-07-07T05:07:23.000+0000

@Dolf Schimmel : ?? Marcel Kloubert use PHP 5.2.6 ( > PHP 5.2.4) and I use PHP 5.2.9, MySQL 5.1.30 (last wamp version) and ZF 1.8.4 (last stable release)

Posted by Alex Frenkel (sirshurf) on 2009-07-29T02:50:08.000+0000

Sorry to make a point, I am using the latest Zend_Core for i5, and it has a 5.2.6.

I have this problem too and I used a fix by Florent PELLET.

Now it works correctly.

Since I dont know how to reopen it, I am voting for this fix.

Posted by Thomas Weidner (thomas) on 2009-07-29T04:59:11.000+0000

I can not fix something which does no longer exist since almost 2 months. Eighter use the latest Release or handle the warning in another way. Voting for a already fixed issue is somewhat useless.

Have you found an issue?

See the Overview section for more details.


© 2006-2018 by Zend, a Rogue Wave Company. Made with by awesome contributors.

This website is built using zend-expressive and it runs on PHP 7.