CiviCRM Community Forums (archive)

CiviCRM does not have any timezone support as yet. This is a missing feature and we hope to rectify it  in a future release

Currently Civi inherits the timezone from php. So most likely your php.ini is set for GMT which is approx 8 hours ahead of PST

lobo

Currently Civi inherits the timezone from php. So most likely your php.ini is set for GMT which is approx 8 hours ahead of PST

Civi pulls the TZ from line 32 of the php.ini file.

Donald and Jason, thank you for the insight, but unfortunately I don't think we're barking up quite the right tree:

I checked and found that the time zone in my php.ini file was set to CST, not GMT as supposed above. I changed it to EST, and now running echo date('l jS \of F Y h:i:s A'); produces the correct (local) time, but CiviCRM is still spitting out times in GMT/UTC.

I do notice that in my php.ini file the time is set on line 13 (as date.timezone = America/Detroit) rather than on line 32 as Jason anticipated above. Could it be that CiviCRM is somehow failing to read the time from the php.ini file (either due to this or another issue - possibly a problem with the path?), and therefore defaulting to GMT/UTC?

Make a file with the following and call it from a browser. It will tell you where it's getting stuff from:

Results are:

Configuration File (php.ini) Path   /opt/php53/lib
Loaded Configuration File   /home/gleaners/php.ini

and

date

date/time support   enabled
"Olson" Timezone Database Version   2012.3
Timezone Database   internal
Default timezone   America/Detroit

Directive   Local Value   Master Value
date.default_latitude   31.7667   31.7667
date.default_longitude   35.2333   35.2333
date.sunrise_zenith   90.583333   90.583333
date.sunset_zenith   90.583333   90.583333
date.timezone   America/Detroit   America/Detroit

Making the same thing for another domain on the server (that does not have its own .ini file) produces:

Configuration File (php.ini) Path   /usr/lib
Loaded Configuration File   /usr/local/lib/php.ini

and

date/time support   enabled
"Olson" Timezone Database Version   2010.9
Timezone Database   internal
Default timezone   America/Chicago

Directive   Local Value   Master Value
date.default_latitude   31.7667   31.7667
date.default_longitude   35.2333   35.2333
date.sunrise_zenith   90.583333   90.583333
date.sunset_zenith   90.583333   90.583333
date.timezone   no value   no value

So, I guess this means that CiviCRM is ignoring the loaded .ini file in exchange for the default one, and then is ignoring the default timezone in favor of date.timezone, which is unset, and thus it is defaulting to GMT?

Does that sound right? And if so, is there any way to fix that without altering the default .ini file (which I can't do because it's a shared hosting environment)? It seems like somewhere in the depths of CiviCRM there ought to be some code that could be tweaked, but I have no idea where to look for it....

EDIT - This indeed seems to be the same issue that jimurl was wrestling with here: http://forum.civicrm.org/index.php/topic,26132.msg110506.html#msg110506
but unfortunately he did not come up with a fix that applies to my situation - as he said:

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.

civi  does not decide what .ini file php reads to intialize various settings. It makes the assumption that the settings are valid and uses them as is

Lobo - simply running date() produces the correct time. PHP knows what time zone it is working with, CiviCRM does not. Therefore, CiviCRM is, at some level, making a choice that is different from what a "normal" php script would do. To all appearances, CiviCRM is not "using the settings as they are" - it is disregarding them, and doing something else.

Update on the above - in search of a more universal solution, I added

date_default_timezone_set('America/Detroit');
to civicrm.php. This seems to have had the desired impact on everything I care about, including most notably the transaction time listed in e-mail receipts. Still ugly and not update proof, but it works, which is more than I can say for relying on php.ini.

Guyiac - Glad it helped!