I never heard that toString() returns an object. Even in Java toString() returns a string and not a object.

I believe what this is after is making Zend_Date immutable.

Though I'm having difficulties finding the "programming standards" the reporter is talking about.

When I have a date and make calculations I expect the calculations to take place.

$date = new Zend_Date();
$date->addWeek(1)->subDay(2)->setYear(2008);
print $date->getIso();

In the above case I expect the date object to hold the calculated value. Why should I be forced to save the return value to a new variable and expect the date object not to be changed ?

When I don't want to change the date object I have to clone it as within every language. This preserves the original object/instance.

$date = new Zend_Date();
$date2 = clone $date;
$date->addWeek(1)->subDay(2)->setYear(2008);
print $date->getIso();
print $date2->getIso();

OK, here's some comment again... :)

1) I apologize for useing 'programming standards', I admit that the use of it is not correct. 2) I wanted to use the Zend_Date in a calendar, and it's really annoying if you have to clone each time, just to make a button that refers to the next/previous daay/week/month/year 3) I didn't necessary mean to make Zend_Date immutable after creation. That would be some kind of overkill, I think... 4) I don't see much benefit of add/subtract methods in this context. I would use setters for setting a state of an object (setDay($this->getDay() + 1)), I would use add/sub-methods for returning a new object. As a solution you could add another parameter (boolean) to the add/sub methods to tell whether it should modify the object or return a modified clone of itself.

And as a small side note: the source code of Zend_Date is REALLY unreadable... :s (the _calculate() method is about 1300 lines!) that's a pity (but this is a personal feeling, I don't know how other people think about this :))

The fact that you can't read the code of Zend_Date and don't know how date calculations work internally has nothing to do with this issue.

Definetly no: The adder, subber and setter methods work always for the object. This will not be changed. Adding a day means that this object is altered.

There is no benefit for users to have 400 new lines just to have an optional parameter which changes OOP behaviour in a way which is a bad coding standard.

You could simply extend Zend_Date and change the needed add/sub methods to return what you need.

Closing as won't fix