SuiteCRM 7.8.31 log file php.ini error inconsistent with php.ini contents

7.8.31 running on CentOS 7 and using php 7.0. My log file is full of “…[-none-][FATAL] Configuration variable date.timezone is not set, guessed timezone UTC. Please set date.timezone=“UTC” in php.ini!”.

However, I have checked that /all/ php.ini files I could find on the server, including the one that seems to be used by php-cli and the one used by httpd do contain the line

date.timezone = “UTC”

How can I troubleshoot the origin of this error message given the above?


You can upgrade you SuiteCRM to current version. I saw the problem in 7.8.x version on my installations but it isn’t in version 7.10.x and 7.11.x . I didn’t study the reasons.

For CLI, what do you get with this command?

php -i | grep timezone

And for web server, in Admin / Diagnostics / phpinfo, what is the effective value of date.timezone there?

For CLI, php -i | grep timezone results in:
Default timezone => UTC
date.timezone => UTC => UTC

For the webserver, I have:

date/time support enabled
timelib version 2016.02
“Olson” Timezone Database Version 0.system
Timezone Database internal
Default timezone UTC

Both look fine to me, or?

I have migrated from SugarCRM 6.5.27 and tried both this version, 7.8.31, and later versions. However, I could never get e-mail functionality to work as expected beyond 7.8.31 so I am stuck here…

As an aside, even this version, this late release of 7.8, seems to have some bugs that I would not have expected to slip through:

  • This php issue as you suggest.
  • A couple of “undefined” in buttons rather than the expected text.
  • My sugarcrm.log is also full of “Fri Jun 25 02:10:03 2021 [63578][1][ERROR] Pop error level. Try to remove the error_reporting() function from your code.” Since I have not written any code myself, I am not sure what generates this message. Nor how to track it down since the error message does not, as far as I can tell, tell me which file I need to take a look at…


I recommend not to deal with errors. Try latest version. Feel free to post your concerns in the community and i am sure someone will help you.

You can start from:

  • install new version as a test zone.
  • install addition modules (if you are using them)
  • copy database from current version.
  • copy custom files (if you created them manually).

Agree with p.konetskiy, don’t mind every single message in the logs. There are many. You should turn them off from appearing on screen with display_errors= 0 in php.ini.

The timezone should be ok, the error message is probably bogus…

I already tried various later versions in docker and found that the e-mail functionality was broken. After posting in this forum, I was recommended to stay with 7.8.31 since later versions do have problem with this key functionality.

Since one of the key functions of a CRM is e-mail functionality I left it at that.

They are not appearing on the screen, only in the log.

However, I really don’t understand this argument which basically says that I should not be able to use the sugarcrm.log to look for important warning/error messages because it is swamped by bogus messages??

I’m not saying to skip the logs entirely, I am just saying you should be ready for a few bogus messages. Especially if you plan to run a version that is about 20 releases behind the most current - some of those things have been fixed a long time ago…

I made a logging PR to help remove the useless stuff and focus on what is important:

1 Like

Well, since there seem to be some serious e-mail issues with later versions that precludes upgrading and I am stuck at 7.8.31. E-mail is such a crucial component of a CRM that any such problems are unacceptable.

It is my opinion that before a the final version is released bugs should have been squashed. Fixing these bogus messages would not have been hard and if someone can tell where they originate I will fix them myself.

I forgot to add that the bogus message I have described show up every(?) minute, most likely resulting from a cron job. So it’s not just a “few” bogus message, it swamps whatever useful information the errorlog otherwise might contain.