WordPress Time Zone Problem

[aglozier]

I'm having problems with CiviCRM displaying GMT in various places.  Some of these are:

• Data Entry - Time defaults to GMT.
• Change Log - Time is GMT
• Scheduled Jobs - Last run time is GMT.  However, logs show local time.

This happens on both our production server (HostGator) and test server.  The test server is a computer in my home on which I installed the TurnKey Linux WordPress Appliance and CiviCRM.

I've searched this forum and found that several others have had this problem.  However, none are running WordPress.  I've done all my trouble shooting so far on the test server.  Based on the posts I read, I've done the following:

• Checked and corrected my system and hardware times.
• Set the time zone in both PHP.ini files (Apache and CLI).
• Tried setting the timezone in the civicrm settings file. i.e. ini_set('date.timezone','America/Chicago');

None of the above worked.  I checked the local time in PHP CLI using this command: php -r 'echo date(DATE_RSS);'.  I get the correct time.

Does anyone have any suggestions?  Is this an issue with the WordPress version?

George

[aglozier]

I have an update.  I figured out how to embed PHP code in a WordPress post.  I embed "echo date(DATE_RSS)" in a test post.  It displays GMT.  So the problem is not CiviCRM.

Any ideas on how to trouble shoot this?

For those interested, I installed the "Allow PHP in posts and pages" WordPress plugin.  Here's what I put in the test post:

<phpcode>
<?php echo date(DATE_RSS); ?>
</phpcode>

[aglozier]

I found the problem.  Once I realized it wasn't a CiviCRM problem, I searched for WordPress PHP time zone problems.  I found it here:

http://name1price.com/how-to-get-customers-with-singapore-web-design-basic/wordpress-tutorials/128-setting-the-default-timezone-in-wordpress.html

Line 32 in the wp-settings.php file sets the time zone to UTC (i.e GMT).  You have to change it to your time zone.

I applied the fix and it corrected the problems I listed in my original post.

[SandraC]

Has anyone else tried this with success? If I muck around this php file has it broken anything CiviCRM? I guess my question: is this Civi-approved or is that a non-issue? Thank you!

[Donald Lobo]

this seems like a lot better fix:

http://issues.civicrm.org/jira/browse/CRM-12523

This fix is part of 4.3.3

no need to hack WP core (or Civi core)

lobo

[aglozier]

I'm not sure the fix in 4.3.3 fixed all the time zone issues.  In particular when you enter a new contribution the 'Time Received' defaults to UTC not local time.  The mod to " wp-settings.php' makes the default local time.  This was one one reason I originally investigated this.  The other was the CRON run times which I didn't check to see if 4.3.3 fixed.

I tested this by upgraded a vanilla 4.3.1 test installation I have to 4.3.3 and then selecting add new contribution.

[Donald Lobo]

I did a quick simple test locally (i had set my TZ in WP to be pacific) and it seemed to work fine for the new contribution page in the latest 4.3.x

in general, we dont recommend hacking either civi or wp. so would be good to try and fix this in most/all places. So would be great if you can track down whats happening and why and submit a patch once u find the bug

lobo

[aglozier]

I agree that you don't want to hack the code and that it would be best for CiviCRM to set the time.  But in this case I believe the WordPress code is designed to let you set the time zone.  Here is the code:

Code: [Select]

// Set default timezone in PHP 5.
if ( function_exists( 'date_default_timezone_set' ) )
date_default_timezone_set( 'America/Chicago' );Normally it reads UTC.

Until I can figure this out, I'll have to hardcode the time zone.

[SandraC]

Thanks for all the responses. Since we are still in development, we will move forward with the upgrade and see what that "fixes". The go to the WP php file after that...

[SandraC]

Update: We did upgrade to 4.3.3 and the Time Zone did not adjust correctly. I did have to go into the wp-settings.php file and set the default time zone to 'New York', and also changed it in settings in Wordpress dashboard. Date is now showing correctly in CiviCRM. (For example, when adding a contribution for an individual contact, the time did show the correct time.)

Thank you to all who share in this forum, I find it very helpful as a beginner! Peace! 

[Dennis Gray]

CiviCRM 4.3.4 installed
WP  3.5.1

I solved my problem

In the dashboard, I set the time to local time ICT.
In wp-config.php I set default time zone to ICT.
It is my server (Rackspace) so I set the tzdata with dpkg-reconfigure tzdata to ICT

Emails now go out immediately.

[rd11]

I'm not sure the patch fixed all of the timezone issues either. Particularly: scheduled jobs (*when executed through the cron.php URL method*) still show UTC time even though other dates reflect the proper timezone.

Going to put the workaround hack in the config files until it's fixed.

[aglozier]

I noticed that with the CRON back when I first investigated this and found the hack.

[viusdeveloper]

I'd like to reiterate that on CiviCRM 4.3.5 this is still broken on the cron.php execution path.
I've noticed that when running scheduled jobs manually, they correctly adjust their timezone (likely because CiviCRM is running inside the Wordpress "context".

However, when running a cron job against /bin/cron.php directly, the timezone offsets are different. This is causing Jobs scheduled to run at say 8AM EST to actually run at 8AM GMT when cron triggers them, but to run at 8AM EST when run manually via /wp-admin/.

Since the cron.php file is being called directly, and not as part of Wordpress, it seems a better solution to this would be if CiviCRM tied the cron.php execution into the existing wp-cron.php functionality that's used on Wordpress sites. At the moment, it doesn't appear to be using that as setting a cron job up for wp-cron.php doesn't cause the CiviCRM scheduled jobs to run.

[Donald Lobo]

i dont know if wp-cron.php is extensible, if so might be good to write a small plugin to hook civi's cron.php to wp's wp-cron.php

civi needs to handle the tz setting from the CMS in a better manner. right now it just uses the default setting from php

lobo