Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64232
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain imhonet.ru designates 78.47.38.178 as permitted sender)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
Date: Mon, 10 Dec 2012 19:18:06 +0400
To: "internals@lists.php.net" <internals@lists.php.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Organization: Imhonet
Message-ID: <op.wo3wsgnzc8onze@debian-nnefedov.local>
User-Agent: Opera Mail/12.11 (Linux)
Subject: DateTime improvement
From: nnefedov@imhonet.ru ("Nikita Nefedov")

So there had been at least two or three messages (subjects) about DateTime  
object and everytime there was this problem - people tend to take DateTime  
object as mutable object and it really is.
As long as we know, it's not so good - date is immutable by nature. I  
don't want to write here why it's so, I will just throw this link:  
http://www.ibm.com/developerworks/java/library/j-jtp02183/index.html

I don't want to change any existing functionality, because some people  
already use it, but I just wanted to point out that current DateTime class  
is forcing people to think about it as mutable.
My main concerns are DateTime#add() and DateTime#sub(). The problem is -  
they both change current object and return it.
I think we could add methods to DateTime like add() and sub(), let's say  
plus() and minus(), but they would behave differently in the way that they  
would return new DateTime objects and won't change current object.

Here's gist to make it clear: https://gist.github.com/4250785

Also, there's methods compareTo, createFromTimestamp and createFromDay, it  
could be another proposal. I think we are very often create DateTime  
objects just from timestamp or year-month-day. So we could introduce this  
methods that could not rely on timelib's parsing, and instead just take  
numbers directly.
And I think DateTime lack comparing method. For now I can compare DateTime  
objects only by getting their timestamps, but I though that the idea of  
DateTime was to go away from using timestamps and instead use well thought  
out api.
Anyway, I think this three methods should be considered as another  
proposal (because they are solve different problems).

Even if this proposal doesn't go far, I think we should do something with  
DateTime. I think I'm going to create user-land library for dealing with  
some of this problems.
But if it pass, I will make patch.