Re: DateTime improvement

Hi!

Date is immutable, but there's no reason why date object should be able to represent only one date. Reference to Java is not exactly applicable here, as many problems existing in Java (thread safety, long-living object references, etc.) do not exist in PHP.

Say we have a blog post entity, it looks like this: Post Object (

    [title] => Qwerty
    [body] => Lorem ipsum
    [craetedAt] => DateTime Object
        (
            [date] => 2010-10-23 00:00:00
            [timezone_type] => 3
            [timezone] => Europe/Moscow
        )

) Now we have some third-party service that we need to use to send our post somewhere, it has a method that accepts title, body and DateTime object when the post was created. So we pass our DateTime object to that method and it can do with that object whatever it wants. When our script ends, it tries to persist all changes to entities and this date will end up in the database. Or we can watch at that problem from ORM's side - when it fetches rows and maps them to objects, it should "remember" original state of that data, so it can distinguish what objects need to be UPDATE-d in database in the end. So there's to ways for ORM to think about dates - as strings/timestamps (it could be database's representation of date like "2010-10-23" or just integer with timestamp) or it could be objects of DateTime. More efficient and logical way would be objects, but that way you must aware users that they shouldn't modify values of DateTime objects, and instead they should create new instance when they want to change value of datetime type. And it's just bad that there could be situations when the entity will represent different data, after persisting, than database.

It does not - if you don't need it mutable, don't use modify() or override modify() with method that would clone the object and return modified clone. This can easily be done in userspace if you require an immutable object, which most of the users actually do not.

I was speaking not about modify() but about add() and sub(). Actually I don't like these two methods (plus and minus) that I proposed too, but how can we solve this problem differently? What about user-land implementation - there's one problem: I can't just extend DateTime object, because it has factory methods like createFromFormat, so I need to use decorator pattern and from that point hell begins.

Timestamp doesn't need any timelib parsing AFAIK, but YMD certainly does - you need to calculate the actual timestamp according to current timezone, etc.

I meant I must either call create new DateTime and pass to constructor timestamp string starting with @ (and there would be parsing involved) or call createFromFormat and pass "U" as second parameter and timestamp as first one.

DateTime objects can be compared directly, why do you think you can compare only timestamps?

My fault, didn't know about that.