Hi! > 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.
You need not be aware of anything unless your database identifies dates by object identities, which is usually wrong since DateTime is a value type in most systems, and should be identified by value, as I already noted. If your data are mutable (which I assume they are, since otherwise the question of saving would not arise), you have to treat changes in title, body, etc. fields - treat the changes in createdAt field the same way. > 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. It is true that createFromFormat and other factory methods could use an extension that allows to instantiate child classes, however working around it is pretty trivial, not sure what "hell" begins there. > 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. Yes, but what's wrong with that? It works just fine. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
