Zend Framework

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

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'..

Closing as non-issue

@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.

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:

protected function getUnixTimestamp()
    {
        if($this->_unixTimestamp === null) return null;

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

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.

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)

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.

dann halt nicht ... grummel

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.

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

@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

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

@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)

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.

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.