V8.4.0-beta changes log times (zone)

pjdm · 7 August 2023 17:20

My timezone is set to local time in Calgary and was showing properly. I tried to delete from IMAP one email. I got a blank screen so checked suitecrm.log. The log output went from local time to GMT time. Checking the log shows a few places where it switches back and forth between my local and GMT.

I do not recall this in previous versions. See the break in the following log about halfway down it jumps from 10:39 to 16:39.

PHP 8.2, v8.4.0-beta, ubuntu 20.04 LTS dedicated server, mariadb 10.6

Mon Aug  7 10:39:01 2023 [99441][1][DEBUG] ----->Scheduler did NOT find valid job (Removal of documents from filesystem) for time GMT(2023-08-07 16:39:00)
Mon Aug  7 10:39:01 2023 [99441][1][DEBUG] ----->Schedulers->deriveDBDateTimes() got an object of type: Scheduler
Mon Aug  7 10:39:01 2023 [99441][1][DEBUG] ----->got * day
Mon Aug  7 10:39:01 2023 [99441][1][DEBUG] ----->got * months
Mon Aug  7 10:39:01 2023 [99441][1][DEBUG] ----->Scheduler did NOT find valid job (Prune SuiteCRM Feed Tables) for time GMT(2023-08-07 16:39:00)
Mon Aug  7 10:39:01 2023 [99441][1][DEBUG] ----->Schedulers->deriveDBDateTimes() got an object of type: Scheduler
Mon Aug  7 10:39:01 2023 [99441][1][DEBUG] ----->got * day
Mon Aug  7 10:39:01 2023 [99441][1][DEBUG] ----->got * months
Mon Aug  7 10:39:01 2023 [99441][1][DEBUG] ----->got * dates
Mon Aug  7 10:39:01 2023 [99441][1][DEBUG] ----->got * hours
Mon Aug  7 10:39:01 2023 [99441][1][DEBUG] Constraints: start: 2015-01-01 08:45:01 from: 1970-01-01 00:00:00 end: 2023-08-08 16:39:02 to: 2023-08-08 16:39:02 now: 2023-08-07 16:39:01
Mon Aug  7 10:39:01 2023 [99441][1][DEBUG] ----->Scheduler did NOT find valid job (Google Calendar Sync) for time GMT(2023-08-07 16:39:00)
Mon Aug  7 10:39:01 2023 [99441][1][INFO] Get One: |SELECT id FROM job_queue WHERE execute_time <= '2023-08-07 16:39:01' AND status = 'queued' ORDER BY date_entered ASC|
Mon Aug  7 10:39:01 2023 [99441][1][DEBUG] Limit Query:SELECT id FROM job_queue WHERE execute_time <= '2023-08-07 16:39:01' AND status = 'queued' ORDER BY date_entered ASC Start: 0 count: 1
Mon Aug  7 10:39:01 2023 [99441][1][INFO] Query:SELECT id FROM job_queue WHERE execute_time <= '2023-08-07 16:39:01' AND status = 'queued' ORDER BY date_entered ASC LIMIT 0,1
Mon Aug  7 10:39:01 2023 [99441][1][INFO] Query Execution Time:0.00014495849609375
Mon Aug  7 10:39:01 2023 [99441][1][DEBUG] Hook called: ::server_round_trip
Mon Aug  7 10:39:01 2023 [99441][1][DEBUG] Calling MySQLi::disconnect()
**Mon Aug  7 10:39:01 2023 [99441][1][DEBUG] Calling MySQLi::disconnect()**
**Mon Aug  7 16:39:14 2023 [2028][-none-][DEBUG] current_language is: en_us**
Mon Aug  7 16:39:14 2023 [2028][-none-][DEBUG] Found cache backend SugarCachesMash
Mon Aug  7 16:39:14 2023 [2028][-none-][DEBUG] Found cache backend SugarCacheFile
Mon Aug  7 16:39:14 2023 [2028][-none-][DEBUG] Found cache backend SugarCacheMemory
Mon Aug  7 16:39:14 2023 [2028][-none-][DEBUG] Using cache backend SugarCacheMemory, since 999 is less than 1000
Mon Aug  7 16:39:14 2023 [2028][-none-][DEBUG] Found cache backend SugarCacheZend
Mon Aug  7 16:39:14 2023 [2028][-none-][DEBUG] Found cache backend SugarCacheMemcached
Mon Aug  7 16:39:14 2023 [2028][-none-][DEBUG] Found cache backend SugarCacheAPC
Mon Aug  7 16:39:14 2023 [2028][-none-][DEBUG] Found cache backend SugarCacheMemcache
Mon Aug  7 16:39:14 2023 [2028][-none-][DEBUG] Found cache backend SugarCacheWincache
Mon Aug  7 16:39:14 2023 [2028][-none-][DEBUG] Found cache backend SugarCacheRedis
Mon Aug  7 16:39:14 2023 [2028][-none-][INFO] Found language file: en_us.lang.php
Mon Aug  7 16:39:14 2023 [2028][-none-][INFO] Found custom language file: en_us.lang.php
Mon Aug  7 16:39:14 2023 [2028][-none-][INFO] Query:SELECT id, name, symbol, conversion_rate FROM currencies WHERE status = 'Active' and deleted = 0
Mon Aug  7 16:39:14 2023 [2028][-none-][INFO] Query Execution Time:0.00018095970153809
Mon Aug  7 16:39:14 2023 [2028][-none-][INFO] Query:SELECT category, name, value FROM config

pgr · 7 August 2023 21:56

You need to set time zone in two places, one for web server PHP, the other for CLI PHP, which SuiteCRM uses for the schedulers.

pjdm · 8 August 2023 18:32

Actually, you set it in three places, including the admin panel. php.ini is a server admin task not a CRM admin task. The developers need to split out server stuff from user stuff and check that the proper settings are in place otherwise everyone including @pgr will fight this forever and SuiteCRM will continue to have a lousy reputation for new users trying to assess the first try. I say stop the new issues and fix everything broken including the deprecations and the logs filling up with 3-year old stuff and php.ini settings across multiple places. Make one pre-flight install that works first time or don’t release it, is my suggestion. Asking casual users to to upgrade from php 8.0 to 8.2 is a lot of work then telling them the installation can’t read the ini files in three places to reconcile time zone is naturally going to cause a large percentage of users to have problems.

Step back. Fix the PRs already there and make the debug scenario more useful as @pgr has posted years ago. Why are we waiting for the debug files to tell us where the failures and warnings occur?

@pgr is acting as the debug statement for much of the warnings and fatals. Why are we asking a human to keep doing what can be coded? I don’t get it.

pgr · 9 August 2023 11:33

Thanks for the support, and yes, it’s quite crazy that my two PR’s “Improved Logging” and "Improved Diagnostics"are not merged yet. I’ve reminded SalesAgility people countless times of them, to no avail. It’s utterly frustrating.

Whenever I see threads here that would benefit from those PR’s, I made up my mind to not answer them. I’m tired of wasting my time doing the same things over and over, needlessly.

On the other hand, some of the things you mention are not as easy at it would seem. There are many things that SuiteCRM will never be able to control about the environment where it runs. The admin stuff, most often, really needs to be set up correctly before SuiteCRM can try to do its magic. On shared hostings, most PHP commands that try to alter the environment will fail due to security limitations.

But at least SuiteCRM could try the changes, and inform the user about what is wrong. My Diagnostics PR gives a vision of both PHP environments (CLI and web server) and focuses on all the things that I know from experience are causes of users getting tripped.

It would benefit a lot, for v8, to add diagnostics specific to the problems with web root configurations, and mod_rewrite configurations. Almost everybody is tripping on that.