There seems to be a bug with Time Conditions. My system is set to use UTC and the system timezone is set to PST. However, the Time Condition is only checking against the system time (=UTC) without consideration for the system timezone.
This behavior seems to be aligned with the time shown on the Time Conditions page which reflects the same behavior.
A temporary solution is to override the timezone in the Time Condition itself.
Hope this can be fixed in a future release.
I can confirm this is an issues with the systems I manage as well.
Manually setting the time zone in each time condition solves the issue.
Have you tried to restart your PBX. We stated after a time zone change at the system level you need to restart the box.
Tony, I am in the process of migrating from Elastix to FreePBX. As such, I am doing regular reboots to (hopefully) overcome some NAT issues I am having.
So, no, a reboot did not resolve the issue. It should also be fairly simple to replicate the issue. Here is a brief description of my environment.
System time is set to UTC
System timezone is set to PST
=> date command shows proper date and time
FreePBX is set to PST in System Admin
=> Time Conditions screen shows system time as UTC (!) which is also used to validate the condition
Hope this help. I am more than happy to do some more testing if needed.
Please detail the commands you are running. (for instance I think you are confused what is âSystem Timeâ how are you getting that value)
Andrew, I am certainly not a linux expert, but I ran the following commands to validate my system.
I specified during the installation that the system clock is using UTC and PST (Los Angeles).
hwclock -r --utc
=> Shows the proper local time (PST)
date
=> Shows the proper local time (PST)
Time Condition page in FreePBX shows system time as UTC (PST+8).
Please let me know if you would like me to run any other commands.
What you have pasted shows that the system time is correct.
So run this:
php -r 'echo date_default_timezone_get() . "\n";'
Hi Andrew,
Here is the output from the php command as requested:
PHP Warning: date_default_timezone_get(): It is not safe to rely on the systemâs timezone settings. You are required to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected âAmerica/Los_Angelesâ for âPST/-8.0/no DSTâ instead in Command line code on line 1
America/Los_Angeles
I donât know PHP very well, but it seems that the system is defaulting to the America/Los Angeles as well. Not sure on the meaning of the PHP warningâŚ
Please let me know if you need anything else and thank you for looking into this.
I ran into a similar issue recently on our install. In the FreePBX System Admin, I had the timezone set to America/New York. Running the âdateâ command at the command line reported the correct time for America/New York. Repeated reboots did not fix the time reported in the FreePBX Time Conditions module. Here is what did:
Not sure if this is related but I just had one switch to UTC. In the GUI itâs set to Pacific
and in the command line doing Date provides the correct time
but in the GUI it shows UTC.
And yes, I did reboot the system (and for the heck of it restart the ntpd service), and no the time zone has never been changed.
PBX Firmware: 10.13.66-6
FreePBX 13.0.38
Just saw this. I just changed the time zone, hit submit, changed it back, and hit submit again and it shows the right time in the GUI now without rebooting. Buuuuut it still doesnât work right. You can see in putty that itâs using UTC.
edit: after doing it the longer way (change time zone, reboot, change time zone back, reboot again) it still isnât working. This is getting really frustrating.
Looking in the logs I see that for at least the last couple days itâs been using UTC. The first log entry is:
[2016-01-04 03:29:01] Asterisk 13.6.0 built by mockbuild @ jenkins2.schmoozecom.net on a i686 running Linux on 2015-11-24 14:38:56 UTC
I cant say if this actually fixed anything or if it was a coincidence but I did a
hwclock -w
to sync the hardware clock to the âsystem timeâ and then everything started working like it should again.
Asterisk aside. You can set the PHP timezone in php.ini. Thats what system admin is supposed to do. From all of our testing it does do that. Try setting the timezone to something else and then back back and see if it fixes it. If it doesnât then I will guide you on how to set this manually.
I can confirm that it is possible to correct the time shown under Time Conditions by setting the timezone in System Admin and doing a reboot.
However, I am not clear on what we are trying to accomplish here. I already identified a workaround (setting the timezone under Time Conditions) in my first post.
And, regardless of if I can set the timezone under System Admin, it is not working properly right after completing the installation. Furthermore, some folks above are reporting that the system might eventually reset itself to the wrong timezone again.
So, setting the timezone under Time Conditions is the best workaround until the actual bug is being resolved.
To be very honest with you. You are calling this a bug but there are no bug reports about it. From our standpoint there is nothing to resolve???
I would like to say though that while preparing for this last deployment, I probably ran the install at least a dozen times (just playing with different features, configurations, etc) and every install had the same problem. Although I selected the Time Zone during install, System Admin reflected the correct name of my Time Zone, and running âdateâ from the CLI reflected the correct local time, the Time Conditions module reflected UTC time after every install. Every install required some effort to have FreePBX report the correct local time.
So, I personally was unable to narrow down where the problem was being generated, thus unable to provide any valuable troubleshooting information. But, it happened on every single install I ran. Interestingly, I had another problem which is probably not related, but could possibly. After a fresh install, the Rest Phone Apps wouldnât work. I double-checked the firewall settings, confirmed the port numbers, but they simply wouldnât work. To fix it, I had to go to System Admin ----> Port Management, and without changing a single setting, I had to press âUpdate Nowâ on that page. After doing that, the Rest Phone Apps worked fine. So, although it may not be related, it does seem that System Admin is not applying some settings correctly and is requiring some user intervention before the settings are applied.
I hope that helpsâŚ
In the newest sysadmin, time conditions and hotel wakeup calls it displays the active server time with the timezone. If someone runs into the issue again please let us know as running âdateâ on the CLI doesnât make a difference to PHP, that only applies to Asterisk and Apache. EG you can run date all day long but PHP could be something totally different
Also if anyone has set this in System Admin and it was still showing the wrong time in the GUI please search php.ini for âAutomatically updated by Sysadminâ and let us know if you find that. If you do post the text surrounding it so we can make sure it actually worked
Since the issues can be reproduced, I am guessing that there is a bug in the installation script. I am also guessing that the timezone reset issue is caused by the same script if it is being reused during system upgrades.
To be fair, I do see a lot of complexity since PHP comes to the mixâŚ
I am sorry that I cannot provide more help on resolving this bug, but my technical knowledge on Linux and PHP is somewhat limited.
From my perspective, it might help to locate the issue in the installation script. I mean the issue can currently be resolved by re-applying the timezone in System Admin. So, I am guessing that the âscriptâ used there is different from the installation script.
Hope that helpsâŚ
I also checked the php.ini file before posting and it showed the correct time zone on mine but the system was still using UTC.
date.timezone = âAmerica/Los_Angelesâ ;;;; Automatically updated by Sysadmin
Timezone information is only set in system admin so no. There is nothing in any installation script(s).
