CiviCRM Community Forums (archive)

Hello Community,

I have been working with timezone settings, having a bit of a time, so here are some notes in case you are experiencing anything similar.

In this case Civi 4.1 on Drupal 6. Drupal's default time zone setting was at America/Denver ( its set at admin/settings/date-time ). User-configurable timezones are disabled, so we are acting as though every user is on Mountain time. I though- hey! good to go. It a VPS account, so I had low level access to alter the timezone settings, if need be.

The linux server tz itself was in timezone America/Chicago.

Some places showed the time corrected for America/Denver, others didn't. For example: the 'Last Activity' timestamp, indicating whenever a contact record was changed - that was correct. On the list of 'Scheduled Jobs Settings' page, which shows a the most recent civi cron job of each type , it showed the correct time for when the cronjobs were triggered.

However, there were places where this timezone designation was NOT being respected: when I set CiviMail to send an email at 1:30 pm Denver time, it would get sent it at 1:30 pm Chicago time. Also on the 'Scheduled jobs Log' page, civicrm/admin/joblog page , the 'Last run' column was incorrect- it showed the times in Chicago time. The main problem, though was the first- sending bulk emails one hour before expected.

PHP has its own timezone settings; so does mysql, you can check what the mysql tz setting is with mysql> select now();
You can check what php's tz setting is by doing a echo date('Y-m-d g:i:s a'); , but it depends where this is run (more about that below). You can also look (if on drupal, and using the devel module) at devel/phpinfo ; or under admin/reports/status/php ; but again,that might look hunky-dory ( as it did for me), while CiviMailings are being sent according to a different tz. you can also create the super-simple info.php file with only this : phpinfo(); same caveat applies, Civimail still may be sent at the wrong time.

So I got to work setting timezone in the places it can be set. I started with the linux server tz, setting it to Denver with something like this: cp /usr/share/zoneinfo/MST7MDT /etc/localtime  (Mountain time)

Restarting mysqld after this will give it a default time zone = server timezone (unless mysqld is passed a default timezone setting as it starts).

I tried setting date.timezone in drupals settings.php file with ini_set('date.timezone',  'America/Denver'); still  no luck. I went to the php.ini file in my site root, public_html . That also did not resolve things!

 

I finally figured this out, becasue I have another domain, for testing, on the same server; and found that the phpinfo(); function there indicated that the default tz was Chicago. When viewed on a drupal page , timezone was being reset by the drupal settings file, and the php.ini file that was in site-root.

But when the CiviMail cron job ran, it wasn't 'bootstrapping' drupal; in fact it doesn't seem to know which domain environment it is running under; it inherits the master default timezone setting.

 
In this case, I could set this by editing the main php.ini file ( it was at /usr/local/lib/php.ini in my case). Not all installations have this as an option.

So if you're running into issues with timezones, the problem may be that some scripts do not 'inherit' the tz setting of the site (domain) that you are working with.

This case was the easy, since all users are in one timezone (not really, but all admins are).

Eileen seems to have identified this issue here:
http://forum.civicrm.org/index.php/topic,23411.msg98329.html#msg98329

with a solution proposed for code that uses timezone conversion at the mysql level, for version 4.3; but if you have shell access, you can follow my short novel above to set default timezone at whatever level works for you.