FreePBX Daylight Savings Issue

So the yearly spring forward has occured, and it appears ALL our FreePBX servers are living an hour in the past still for the System Admin and Time Conditions.

OS configuration is correct:

# timedatectl
      Local time: Sun 2023-03-12 12:17:04 EDT
  Universal time: Sun 2023-03-12 16:17:04 UTC
        RTC time: Sun 2023-03-12 12:17:04
       Time zone: America/Toronto (EDT, -0400)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: yes
      DST active: yes
 Last DST change: DST began at
                  Sun 2023-03-12 01:59:59 EST
                  Sun 2023-03-12 03:00:00 EDT
 Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sun 2023-11-05 01:59:59 EDT
                  Sun 2023-11-05 01:00:00 EST

timezone file is correct

# ls -l /etc/localtime
lrwxrwxrwx 1 root root 35 Mar 12 12:13 /etc/localtime -> /usr/share/zoneinfo/America/Toronto

PHP is showing correct:

# cat /etc/php.ini | grep timezone
; Defines the default timezone used by the date functions
date.timezone = "America/Toronto" ;;;; Automatically updated by Sysadmin
# php -r 'echo date(DATE_RFC2822) . "\n";'
Sun, 12 Mar 2023 12:19:04 -0400

But not freepbx! Going to Admin → System Admin and selecting “Time Zone” it shows the correct time zone but “Server time: 11:20:50 EST”

This isn’t isolated, it’s occurring on all our client FreePBX installs as well, about 30 PBXs all mix of FreePBX14 and FreePBX15 across the board (most 15).

It’s not an OS issue, as none of our others CentOS servers appear to be having this issue… There are no yum updates or system module updates. It just appears that the FreePBX software itself takes the provided DST info and throws it out the window in favor of the flat -5 EST timezone.



Can confirm this is the case for FreePBX 16 as well as various PBXact systems that we have deployed.


You are conflating system time with the PHP timer in the GUI. What is the PHP timezone setting? You can have a system time of UTC and still show it, in the GUI as America/Detroit

In Advanced Settings on the systems that I checked the timezone is set to what’s expected but is still an hour behind.

I am experiencing this as well.

In my system, it’s off in GUI. Phone switched automatically, OS shows correct too.

Same here. My Sangoma endpoints adjusted accordingly despite the wrong server time.

Modules up to date. Yummed regularly…

FreePBX v16.0.33
Distro v12.7.8-2302-1.sng7
Asterisk Version: 18.16.0

      # timedatectl
      Local time: Mon 2023-03-13 08:19:46 CDT
  Universal time: Mon 2023-03-13 13:19:46 UTC
        RTC time: Mon 2023-03-13 08:19:46
       Time zone: America/Chicago (CDT, -0500)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: yes
      DST active: yes
 Last DST change: DST began at
                  Sun 2023-03-12 01:59:59 CST
                  Sun 2023-03-12 03:00:00 CDT
 Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sun 2023-11-05 01:59:59 CDT
                  Sun 2023-11-05 01:00:00 CST


We really need details folks. What release are people running. What versions of things are they running. I’ve checked a couple systems and I can’t see this problem.

Edit: Anyone running FreePBX v14 with this issue, update as that version is officially EOL and won’t get any support/fixes.

My two systems are both running FreePBX 16.0.33 with Asterisk 18.16.0. both are distro systems. All modules are up to date.

I am Central Time Zone and all systems I checked are at the latest of the various flavors (FreePBX 16.0.33 and PBXact 12.7.8-2302-1.sng7).

Pretty sure this isn’t handled by the sysadmin module but just in case it is it’s at

Well, I did a little testing and yup this is 100% a FreePBX issue. System time is in DST, running any php code via CLI or Apache (web) PHP confirms that it is in the right time zone and that it is fully in DST. Only running through FreePBX’s framework/GUI show everything still as standard time instead of DST.

As far as I can tell it’s only a visual bug at this point. Asterisk has the correct time passed to CDRs, Time Conditions, Voicemail, etc. The system and PHP are both correct where ever else they are used, it’s JUST the display at the top of the FreePBX GUI on the system admin Time Zone page, or on the Time Conditions / Time Groups page.

1 Like

Oh this is good to know.

Yeah, it’s almost like someone pointed this out already in here.

Yes, this is GUI only impacting but it’s not really an issue that should be happening.

Oh yeah I understand, but per my original post both PHP and the system timezone are set to America/Toronto and everywhere else is displaying EDT, including other applications like FOP2 have no issues. If you create a .php file to output the current time and nothing else, load it, it’ll be correct.

Actually whats interesting is I checked the UCP, in the user settings page it shows an example of the “current” time and it’s off by an hour, but when new calls come through or you look at your call history in the UCP it timestamps things correctly. Same with Sangoma Connect / Sangoma Phone, all the timestamps are correct.

So I’m curious what the front-end code looks like in freepbx to pull the current time that’s causing the display issue.

Well there are some date/time things that are handled in JS/Jquery. How much of that is client based vs node.js based, not a 100%.

I examined this last night too and came to the same conclusion you are coming to. It’s probably a bug in the JS being used to display system time. Well, it’s not wrong - it IS displaying the correct time in EST!

Adding to this thread as well, since I have users that are using the UCP to look at voicemails. They noticed the time was off. And sure enough, just like everyone else, the system time is correct, UCP is showing the incorrect time.

I’m in Central, so have chosen America/Chicago. Confirmed that is the setting in PHP Timezone in Advanced Settings.

PBXAct 16.0.33


Can confirm this is UI bug only.

  • PBX Version: 16.0.33
  • PBX Distro: 12.7.8-2208-2.sng7
  • Asterisk Version: 16.28.0

Thankfully Asterisk is managing all of our time conditions exactly as it should, with proper timezones and daylight savings time settings.

Really had me worried when I first noticed it this morning!

has anyone reported this issue on the issue tracker?