I just had a rather frustrating experience trying to use a timestamp in a plugin I’m writing. Even though I have my timezone dutifully set in my php.ini file, as all good PHP 5.3.* developers should, the timestamp that WordPress was giving me in the admin section was for UTC instead of America/New_York.
WTF?
After a lot of googling, I found that the wp-settings.php file in WordPress has a rather evil pair of lines:
if ( function_exists( 'date_default_timezone_set' ) )
date_default_timezone_set( 'UTC' );
The purpose of this line is actually not so evil: PHP 5.3 starts barking a lot of errors and warnings at you if you don’t have your default timezone set somewhere in its environment instead of relying on the operating system’s time setting. To stop the barking, WordPress is making sure you have your timezone set to something, namely Universal Coordinated Time.
The catch is that if you have set your timezone in PHP (like in the php.ini file, where it should be), this will override it, instead of using it. That’s bad. But that’s not the whole story.
The WordPress administration itself has a setting for your blog’s default timezone (Settings → General → Timezone) and when you publish a post, it gives it the correct timestamp. So it must know that information somehow. The trick is tapping into that.
The solution: use the WordPress function current_time(). Documentation for it can be found here:
http://codex.wordpress.org/Function_Reference/current_time
Not the solution: modifying the wp-settings.php file to your correct timezone, as I’ve seen suggested in some blog posts and forums. All that will happen is that file will be overwritten to the UTC value the next time you upgrade WordPress.
Best solution: someone should update the WordPress core to read the php.ini’s set timezone as a default, and use UTC only as a fallback.
Update: I twittered about this to a WordPress core contributor, who replied:
Setting to UTC and working off that is really the only sane way to be portable across versions of PHP and countless servers.
I’m not sure I agree with this position, but it appears to be the official one. So one’s only option is to work around it and either set your timezone in your functions.php file or use the WordPress current_time() function.
Again, do not modify the wp-settings.php file (as many of my Google results recommended), because that file will just be overwritten when you next upgrade the WordPress core, causing the problem to reappear.