7

Mailing clicks and opens are registered via scripts in extern (which are quite old) - and don't appear to use the cms environment - as such if the timezone isn't set for php and has defaulted to UTC - this won't show in the warnings - despite it being the issue. To detect this compare the result of php To confirm this is the problem run php -r 'echo ...


6

It turns out that if you are using Wordpress you need to set the timezone to specific location, e.g. London, rather than using the default UTC offset. When I used the London timezone the problem went away. Configure this in WordPress at Settings > General /wp-admin/options-general.php


6

The warning is because the timezone of the server does not match with the timezone set in MySQL. We had similar warning and after setting the timezone in both Centos & MySQL, the warning is not displayed anymore. Additional Info: This is how we corrected/fixed the timezones, if it helps. The below instructions are for setting timezone to GMT, you need to ...


5

With WordPress, 90% of the time it's just the WordPress timezone that needs to be reset. Make sure that's set right as a first step.


4

In testing i determined that all of the UTC offset TZ WordPress offers are invalid from a php perspective. Set the timezone to the proper php TZ (Europe/Zurich for example) and that error will go away.


3

Try setting your preferred timezone in civicrm.settings.php and/or wp-config.php? ini_set('date.timezone', 'Asia/Calcutta'); You might want to adapt the timezone you set as appropriate to your MySQL server. mysql -e 'SELECT @@system_time_zone;' I believe India does not observe daylight savings? For that and similar reasons it's probably better to match ...


3

I second Jon G's answer with this reference -- Jon actually helped on a similar issue I had. The issue was indeed that the php.ini did not specify the time zone. The answer on this question fixed it for me: https://civicrm.stackexchange.com/a/3589/105


3

For us, there were a couple of changes that made this to work. First, in the database, the civicrm activity_date_time type was modified to be a timestamp. This made it so that when CiviCRM saved the date and time it was stored in the database as UTC once the Drupal timezone was also set to UTC (but users are able to select their own timezone and it behaves ...


3

I know you said you checked the user's timezone but did you check the sitewide time zone in Drupal at /admin/config/regional/settings?


3

In my experience with this, you can modify the default timezone setting for your CMS. Not sure how to do this in Joomla, but there are UI options for this in both Wordpress and Drupal so I would imagine that Joomla offers a similar setting.


3

Tim - If the timezone for the event is always the one used by your organization (for example, if you're located in New York, it's always ET), you could modify the Smarty template for event receipts to include the time zone in the date formatting. One example: {$event.event_start_date|crmDate} could become {$event.event_start_date|date_format:"%A, %B %e, ...


2

I have flagged a similar problem with Joomla as an issue a long time ago and submitted some code to solve it: https://issues.civicrm.org/jira/browse/CRM-15656 The CiviCRM team reckon it will be fixed in 4.7.7.


2

wp-cli doesn't bootstrap the settings, so doesn't load the timezone. Because of this exact issue, I wrote a patched version of the CiviCRM extension for wp-cli to add timezone support. It's available here. As far as I can tell, the original author has abandoned the project, because they haven't merged any pull requests (including this patch) in over a ...


2

As long as your PHP and MySQL settings are correctly set (CiviCRM should warn you if they are not), you can set the server time to your preference. Using UTC for the server is probably more convenient on the long term, but it's not a CiviCRM requirement. For example, lets say you are in UTC-8, but next year a new sysadmin joins your team and is in UTC+6, UTC-...


2

An issue has been created for a similar requirement: CRM-17618 - time zone field needed for event creation. You could check whether the requirements described there cover your use case and see if there's scope for collaboration, joint funding etc.


2

No existing fix I know of. It's maddening, and the prime example of this is civicrm.org! The site runs in US Pacific time, so when we have Washington, DC, meetups scheduled, the iCal has the wrong time.


2

Sorry for the delay but was I was able to solve my issue, I had set the time zone in WordPress > Settings > General and then changed from manual offset option to location based offset option. This is due to WordPress and CiviCRM handling time differently than WordPress when using the manual offset method.


2

This question is now resolved. It is not a bug, but a server misconfiguration. I am adding the resolution here for posterity. It turns out the issue was caused by the server being set to Europe/Berlin, but PHP-FPM defaulting to UTC. Setting PHP-FPM to Europe/Berlin through its configuration file solved the issue.


1

The main clue is that these date/times are being stored in mysql datetime fields, which do not include a timezone, but implicitly have a server-wide timezone (either adopted from the server, or configured explicitly). So we know that the problem is at the php level - the code is generating the date time and converting based on the current user's timezone (...


1

I have a similar setup running Drupal 6 and CiviCRM 4.7.25. My system also showed System Status: Critical and no messages. The issue was is that it first attempts to set the time zone and if that fails it doesn't output any further messages for some reason. In CiviCRM version 4.7.25 you can use the API console to run the System.check action by visiting http:...


1

It turns out joomla on the cpanel install in question linux reads the php.ini file from the /administrator directory not site root. I had put one in the root dierctory and had checked if php was reporting it correctly and it was. So now fixed.


1

I've never changed the scheduled date directly in civicrm_mailing, but it seems like a pretty harmless maneuver. If your CMS is WordPress, I have a fork of wp-cli here that lets you specify the time zone in which a cron job should assume it runs. It's specifically to handle a WordPress/Civi multisite where different sites are maintained by users in ...


1

It's a timezone issue. Your database and drupal timezone must be same. Sometime it's happen due to Daylight saving time.


1

Check your timezone setting in Joomla. Go to System, Global Configuration Click on the Server tab and go to Location Settings


1

I have discovered that if I change the timezone for my Drupal user account to 'Europe/Sofia' then I no longer get this error message. This solves the problem, but not in a very satisfactory way as I'm based in the UK and would like the timezone for my user to reflect this. It appears that CiviCRM creates this error message if your Drupal user account isn't ...


1

As an experiment, I edited your CRM/Utils/System/Base.php file and changed: $sql = "SET time_zone = '$timeZoneOffset'"; to $sql = "SET time_zone = 'Europe/London'"; and that seems to have fixed the problem. This is certainly not the ideal solution, but it does work.


1

This is one possible solution. https://beta.suresupport.com/faq/article-1568/en/setting_mysql_session_time_zone Another is setting the 'timezone' property in php.ini or .htaccess file, or in civicrm.settings.php or drupal's settings.php


1

check what's the timezone under /admin/config/regional/settings, drupal can overwrite the php default timezone


Only top voted, non community-wiki answers of a minimum length are eligible