Sonata Stats wrong time on reports

Hello,

I just realized that call reports show time in UTC instead of the timezone set in Report Settings.
Is there a fix for it?

Thanks!
-G

Could you please try to update the report settings and check if the issue persists?

I tried changing it to a different timezone and back. It still shows time as UTC on the report itself.
Also, tried updating PBX to the latest version and still not showing right timezone.

please try to execute these commands from this location /usr/share/sonata/queues-stats/backend

php artisan tinker

App\ReportSetting::all()

please send an image of the data you see on screen

also what’s your pbx and stats version

Capture

you will need to update the settings on the main tenant the timezone is set to utc

That worked.
Is it not possible to have a different timezone on different tenant when it comes to call reports?

Yes you can set report settings for each tenant but the main tenant settings are used by default if no settings exists for a secondary tenant

I had a tenant 21 set to America/New_York and main tenant to UTC. When pulling report on tenant 21 it would show time in UTC. When I changed timezone on main tenant it reflected the change on tenant 21.

Do you have the latest version installed?

I believe so.
VitalPBX Carrier 3.2.3-4
Sonata Stats 1.0.7-5

Changing the Timezone on the main tenant makes any difference?

It does. It changes timezone for all tenants regardless what each tenant has.

Is this happening on every report?

Everything in Call Reports, unless main tenant is set to desired timezone.

Could you please confirm the secondary tenant is id 21 as shown on the screen you shared just to make the settings are being saved properly

Yes, I checked mysql and tenant id matches.

Could you please try replace the file at this location /usr/share/sonata/queues-stats/backend/app/Http/Controllers/Controller.php with the attached file, change the attached file extension to .php and then try again
Controller.txt (755 Bytes)

No change. Do I need to restart anything?

Not necesary, we’ll continue looking for the cause of the issue