I consider these objects dead unless they bother documenting them. An undocumented object is exactly as useless as no object at all.

“Let’s create a great new object-oriented DateTime system!”

“Let’s not give it any useful new functionality, and let’s just use it as a wrapper object around some already-existing and inconsistently-implemented functions!”

“People will get mad if they can’t do EVERYTHING from global functions, so we’d better not actually make dates easier to work with in this class! The functional guys would only get jealous of the OO guys…”

Really, in the world of modern languages, PHP sucks big time. It’s like 10 years old. Various attempts in PHP5 to make it “more OO” only serve to show that Zend don’t actually understand OO.

Anyway: thanks for a good article. Unfortunately I’m still having to work in PHP and needing all the support I can get!

$yesterday = new DateTime(‘yesterday’); $tomorrow = new DateTime(‘tomorrow’); $now = new DateTime(); // ‘less-than’ certainly works: echo ‘Yesterday is before today? ‘.($yesterday < $now ? ‘yes’:'no’).”\n”; // So does ‘not-equals’ echo ‘Today is not yesterday? ‘.($yesterday != $now ? ‘yes’:'no’).”\n”; // and ‘greater-than’ echo ‘Tomorrow is after today? ‘.($tomorrow > $now ? ‘yes’:'no’).”\n”;

Output:

Yesterday is before today? yes Today is not yesterday? yes Tomorrow is after today? yes

$date = new DateTime(“@1192951100″); echo $date->format(‘Y-m-d H:i’);

http://fischer.tecnologia.ws/en/node/1

New York – Mon 3:30 (DST) Paris – Mon 8:30 Sydney – Mon 18:30 (DST) San Francisco – Mon 0:30 (DST) Tokyo – Mon 16:30 ETC…

Is this wishful thinking in PHP or something very obvious to someone with more experience than me?

MAMP is really for prototyping, not a longer term solution.

For most everyday issues, use gmdate functions for storage and putenv(‘TZ=wherever’) to make the local presentation correct and you’re done. Converting a stored gmdate (say MySQL date/time format) to localtime for a given date string is a matter of appending ‘+0000′ onto the SQL string, passing it through strtotime, and then use date() on the result. The +0000 forces strtotime into dealing with it as GMT instead of trying to act smart and adding your local offset. Should be easier, but that ain’t bad.

I’ve got a handy little function I found somewhere in the wild which implements a selector by recursively reading the contents of the zoneinfo dir, sorting it and turning into an HTML SELECT form.

For complicated date/time comparisons/operations across different zones, the only gotcha’ is that you’ve got to put TZ in the environment for each zone you need to work with and change it back to the default when done.

I hear Windows/PHP users have a heck of a time doing this, but this usually doesn’t concern me.

It would be nice if the new classes made this even easier, but from my reading – they haven’t. The only real advantage I can see is that if you’re willing to go through the work, you can have a portable implementation that will run on a Windows box.

And also define a a __toString method, and some accessors and mutators, and probably some convience methods for math. Objects are wondeful!

But as I was playing with the objects it was interesting to see how spare they were, how, un-PHP like. Contrary to how it might seem at first PHP does have a guiding aethestic (just like any other language) and we shouldn’t discrad obviousness and easy to use just because objects have entered the scene. And core PHP classes should model that good design.

(Normally I’d draw some parallel with Ruby here about how they have objects, but they’re still simple and intuitive but Ruby’s Date/Time/TimeZone stuff is a freakshow only slowly getting better)

class BetterDateTime extends DateTime { function setTimeZone( $tz ) { parent::setTimeZone( $tz ); return $this; } function setDate( $year , $month , $day ) { parent::setDate( $year , $month , $day ); return $this; } }