UTC time wrong

Plus it screws up Cron/scheduled posts – As @emily pointed out.
So it’s not just the settings page.

I got the same problem after upgrading to WordPress 4.7 (also with 4.7.1).

On the same server, same PHP settings I have other blogs running with WordPress 4.6.x which correctly report the UTC time.

So this looks like some regression in WordPress 4.7

This issue was present in 4.6 also – And I think also 4.5 (but I didn’t confirm that). I didn’t report/act on it earlier because I figured I ‘needed to sort that out some time’. Which I pushed a few months.

Try this in a PHP script. Not in WordPress, just a standalone script on your server.

date_default_timezone_set( 'UTC' ); 
echo date('Y-m-d G:i:s');

That should, obviously, output the UTC time. Does it?

Hi Otto,

Yea I’ve got that already – https://ajdg.solutions/date.php
Note how the UTC settings show wrong times and the Manila one shows the correct time.

MediaTemple had me redo the timezones on MySQL/MariaDB, they were off too by -5 hours, somehow they assumed that would fix the PHP times too – I don’t see why/how.
Anyhoo, they’re still searching too (i guess) – I think their DV are just configured silly with time somehow and nobody noticed before. They won’t hear that though…

I’ve been having issues in WordPress with my logs and my plugins reporting either UTC or local time but not one consistent time code as selected in Settings > General setting in the WP Admin.

CentOS reports this:

[mike@myserver ~]# timedatectl
      Local time: Sat 2017-01-14 21:31:47 CST
  Universal time: Sun 2017-01-15 03:31:47 UTC
        RTC time: Sun 2017-01-15 09:10:47
       Time zone: America/Chicago (CST, -0600)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
      DST active: no
 Last DST change: DST ended at
                  Sun 2016-11-06 01:59:59 CDT
                  Sun 2016-11-06 01:00:00 CST
 Next DST change: DST begins (the clock jumps one hour forward) at
                  Sun 2017-03-12 01:59:59 CST
                  Sun 2017-03-12 03:00:00 CDT

My Apache httpd.conf has this setting:

SetEnv TZ America/Chicago

My PHP php.ini file has this:

[Date]
date.timezone = America/Chicago

And with PHP CLI, when I run the following command, PHP reports this:

[mike@myserver ~]# php -a
Interactive shell

php > echo date_default_timezone_get(time());
America/Chicago

When I log into MySQL via the command line and run the following query at the current time (9:43pm on January 14, 2017) and get this:

mysql> SELECT NOW();
       
2017-01-14 21:43:26

This verifies that my setup is configured properly on the backend.
Now I go to my PHP code in WordPress.

I have gone into my functions.php file to create some debugging flags. I have simply added this line to my functions file:

error_log('Get reported WordPress GMT offset: ' . get_option('gmt_offset'));
error_log('Get reported WordPress timezone: ' . get_option('timezone_string'));
error_log('Get reported PHP timezone: ' . date_default_timezone_get());

I load up my website, then I turn on my debugging for WordPress and look to my logs to see what is outputted.

[mike@myserver ~]# tail -f -n 300/var/www/www.myserver.com/public_html/wp-content/debug.log

Sure enough I see a series of entries:

[15-Jan-2017 04:03:31 UTC] Get reported WordPress GMT offset: -6
[15-Jan-2017 04:03:31 UTC] Get reported WordPress timezone: 
[15-Jan-2017 04:03:31 UTC] Get reported PHP timezone: UTC
[15-Jan-2017 04:03:31 UTC] Get reported WordPress GMT offset: -6
[15-Jan-2017 04:03:31 UTC] Get reported WordPress timezone: 
[15-Jan-2017 04:03:31 UTC] Get reported PHP timezone: UTC
[15-Jan-2017 04:03:31 UTC] Get reported WordPress GMT offset: -6
[15-Jan-2017 04:03:31 UTC] Get reported WordPress timezone: 
[15-Jan-2017 04:03:31 UTC] Get reported PHP timezone: UTC

The prefix timestamp shows a time in UTC and the
Then I change my timezone settings in the WP Admin > Settings > General from ‘UTC-6’ to ‘Chicago’ (under the America select dropdown group). My debug log now has this:

[15-Jan-2017 04:12:35 UTC] Get reported WordPress GMT offset: -6
[15-Jan-2017 04:12:35 UTC] Get reported WordPress timezone: America/Chicago
[15-Jan-2017 04:12:35 UTC] Get reported PHP timezone: UTC
[15-Jan-2017 04:12:35 UTC] Get reported WordPress GMT offset: -6
[15-Jan-2017 04:12:35 UTC] Get reported WordPress timezone: America/Chicago
[15-Jan-2017 04:12:35 UTC] Get reported PHP timezone: UTC
[15-Jan-2017 04:12:35 UTC] Get reported WordPress GMT offset: -6
[15-Jan-2017 04:12:35 UTC] Get reported WordPress timezone: America/Chicago
[15-Jan-2017 04:12:35 UTC] Get reported PHP timezone: UTC

Okay so now America/Chicago is showing up as what is stored in the WordPress DB, but the PHP reported timezone is still set to UTC (even though we set PHP’s initialization to date.timezone = America/Chicago and verified that it was being reported). That’s really interesting.

Regardless, UTC is permanently being set somewhere in my PHP code at this point!

I search from the base of my website folder through all of the PHP files recursively for the string text of the function that solely responsible for changing ANY timezone in PHP, namely: date_default_timezone_set.

Of the plugins (must-use or otherwise) that contain ‘date_default_timezone_set’, I have completely disabled them and confirm they are not active. I also reset the OPCache to make sure that I am not gathering server cached output.
I do not have any files in my themes that have this ‘date_default_timezone_set’ string. The final output of searched files that are left over are the following:

/var/www/www.myserver.com/public_html/wp-settings.php:51:date_default_timezone_set( 'UTC' );
/var/www/www.myserver.com/public_html/wp-admin/options-general.php:178:  date_default_timezone_set($tzstring);
/var/www/www.myserver.com/public_html/wp-admin/options-general.php:220:  date_default_timezone_set('UTC');
/var/www/www.myserver.com/public_html/wp-includes/class-phpmailer.php:3275:        date_default_timezone_set(@date_default_timezone_get());

Notably, the first and the third stand out to me.

Now, these are core files, I’m not supposed to change these, but there’s clearly something not right here in those two files. What do I do?

• This reply was modified 7 years, 9 months ago by mkormendy.
• This reply was modified 7 years, 9 months ago by mkormendy.
• This reply was modified 7 years, 9 months ago by mkormendy.

After testing both locations and modifying the default_timezoneI ended up commenting out the following line in my wp-settings.php file (roughly around line 51):

// WordPress calculates offsets from UTC.
date_default_timezone_set( 'UTC' );

to:

// WordPress calculates offsets from UTC.
// date_default_timezone_set( 'UTC' );

My posts, custom post-types and debug logs are all reporting their times correctly, on the front-end, the back-end and in the timestamps in the database as well.

The only thing that is reporting incorrectly is the output facade timestamps in the WP Admin > Settings > General:

Universal time (UTC) is <em>2017-01-15 02:12:06</em>. Local time is <em>2017-01-14 20:12:06</em>.

The Universal time is actually the correct local time, and the local time is 12 hours behind universal time (which should be only 6 hours behind).

This probably should be fixed in core. Otto can you look into making that happen?

• This reply was modified 7 years, 9 months ago by mkormendy.
• This reply was modified 7 years, 9 months ago by mkormendy.

When I run Otto’s script, I get the wrong time. It displays my local time, not UTC. There must be some setting in PHP that is causing this? Would it help to post my php.ini file?

No don’t post. Do you see date.timezone in your php.ini? If it is commented out (with a // before it) then there is nothing adjusting your time from your php.ini.

It’s set: date.timezone = America/New_York

I’ve tried commenting it out, and also changing it to UTC, and the issue still persists.

Since the script was run outside of WordPress, it seems to be a PHP problem, not WordPress. :\ Maybe I should look for PHP forums, somewhere.

• This reply was modified 7 years, 9 months ago by Emily.

Well like my previous posts, WordPress permanently sets the timezone to UTC for PHP.

Did you look in your wp-settings.php file for date_default_timezone_set (~line 51)?

I have put in a request to look at this further with the development trac of wordpress. In all honesty I don’t think that WordPress should be designed to hijack the PHP timezone unless it is going to set it back to normal after for other parts of the website to base its time on.

Media Temple fixed it!! Here’s the reply I got from support:

It appears that there was an issue with the time zone database initially provisioned to your server in which the UTC time zone was improperly set to EDT. We were able to resolve this issue by re-installing the tzdata package.

yum install tzdata

It’s now working properly in WordPress. Yipee!!

Same for me @emily, server issue.

—
Arnan,

Thank you for your patience in this matter.

It appears that there was an issue with the server, in which the UTC time zone was improperly set to EDT. For reference, the resolution involved reinstalling the tzdata package with the following command:

yum install tzdata

Your script at https://ajdg.solutions/date.php is now showing the correct values, and this should address the issues you have been experiencing.
—

WordPress and my script now indeed show the right times.

Okay, everybody, stop. You’re confusing things all up here, and talking about editing core, and not understanding how WordPress works with timezones.

(For those of you who got your server to fix it, yay! Good for you, glad that helped!)

YES, this is supposed to be in WordPress:
date_default_timezone_set( 'UTC' );

WordPress sets PHP to treat the default timezone as UTC. WordPress then applies its own corrections for posts and everything else based on the Settings->General screen.

If you’re trying to force PHP to use a different timezone, and you end up commenting that line out, then you’re going to be overcorrecting it.

Your server needs to be keeping time properly in the UTC timezone, like all servers do. Then everything works out properly and correctly.

If you run the script I gave above, this one:

date_default_timezone_set( 'UTC' ); 
echo date('Y-m-d G:i:s');

Then you should get UTC time. Period. If you get *anything else*, then your server has the wrong time configured on it. The server itself. Not WordPress. Not PHP. The server. It’s that simple.

@mkormendy That code is *intentional*. WordPress is applying the timezone corrections, it’s not having PHP do it. WordPress has its own timezone handling system. Yes, it’s not ideal. But it also pre-dates PHP 5. WordPress had timezone support in PHP 4, and the timezone support for PHP 5 was sorta bolted onto it (I did most of that bolting) back when we still supported PHP 4.

Now, it is indeed due to be replaced and to use more normal PHP 5 methods, but you’re talking about a lot of code threaded all throughout the codebase. It’s a big job with a lot of work and not a heck of a lot of benefits. The main problem we had was not the code giving wrong times, but actually that hosting companies rarely updated the timezone_db data, so that timezone info would be out of date on the server itself.

The truth is that PHP adoption (or lack thereof) has been the biggest stumbling block to fixing problems like these, because while anybody can write code to work on one system, WordPress has to work on a large variety of systems. Sometimes, this means using non-optimal methods, backwards compatible code, things like that. Yes, this is setting it to UTC and then manually applying the timezone when needed. But it works pretty well, and really, all servers should know the proper UTC time. If you can’t get that reliably, then there’s no real fix.

• This reply was modified 7 years, 9 months ago by Samuel Wood (Otto).
• This reply was modified 7 years, 9 months ago by Samuel Wood (Otto).

Thanks for chiming in Samuel! And thanks for also considering my findings.

No need to explain the reasons why WordPress does things a certain way. I’ve never questioned the intention behind much of how WordPress has been written, but happy to hear the back-story nonetheless.

This may pop-up again down the road but that comes with the territory of Open Source software. Either way, if and when things are needed to change I’d be happy to contribute.

• This reply was modified 7 years, 9 months ago by mkormendy.