Solved: All about time?

[compsos]

Hi
We have a Debian 9.5 machine running Sail 5.0.0.57+deb9u1 and asterisk 13.14.1
What the issue is the timers are set to start the close at 17:00 and finish 08:59. The date command returns the correct time, the hwclock is set to sync and the phones show the right time.

But the timers seem hell bent on applying Daylight Saving Time and be `1 hour ahead.. Where do the timers get the time from if not the machine or the upstream server? The zone is correct for the district.

Below is correct except it started at 16:00 as Closed
Status
PBX: RUNNING
Master Timer: AUTO
Timer State: CLOSED
SysTime: 17:03:27
System Uptime: 23 days
Has anyone got  a clue on where to trap the error? The logs do not mention the switch or an issue.
TIA

[compsos]

Now I do not think the time source would be in the DB but this is the definition

Code Select Expand

# id pkey cluster datemonth dayofweek desc month state timespan z_created z_updated z_updater
0 2 dateSeg383022 default * sat Sat * IDLE 09:00-16:59 2018-09-27 05:12:52 2018-10-15 07:00:04 system
1 3 dateSeg204082 default * sun Sun * IDLE 09:00-16:59 2018-09-27 05:13:44 2018-10-15 07:00:12 system
2 4 dateSeg288611 default * * AH * *INUSE* 17:00-08:59 2018-10-17 06:27:14 2018-10-19 06:01:01 system

[sysadmin]

Interesting.   Which timezone have you set in Globals please?
What does the date command give you?


   

[compsos]

Sorry for the delay been out on remote sites
TZ zone is set to Australia/Brisbane
Date returns the correct local time as does hwclock
And the phones show the correct time
In the globals side box all looks good except the  Timer State is wrong if you are looking at it within the time window when it should be the opposite. (ie) at 16:00 it should be open but is in fact closed.
And yes it is "interesting"
Also seen another system where 3 phones revert to 15th June 2017 on reboot. This may not be related to this problem, but is still a date issue. Manually setting the date and time is holding this at bay for the moment.

[compsos]

OK have a 2nd  system doing the same
From the Globals
Status
PBX: RUNNING
Master Timer: AUTO
Timer State: OPEN
SysTime: 07:31:38

Sysinfo
PBX release: 13.14.1
SAIL Release: 5.0.0-57+deb9u1
HPE Release: 5.0.0-3
Endpoints defined: 13
Serial Num: 986849

date
Tue 13 Nov 07:34:08 AEST 2018
hwclock
2018-11-13 07:34:32.528883+1000

Timers
18:00    08:30    *    *    *    closed_hrs    
12:30    17:59    sat    *    *    closed_sat    
08:31    17:59    sun    *    *    closed_sun    

It looks like an error in timezone data in that the timers are applying  1 hour Daylight saving that is applicable AESST but not for AEST. But if the clocks are correct, is there a possibility the asterisk is doing it's own adjustment?

[sysadmin]

Hi,

Asterisk is only indirectly involved in time management in SARK.   Most of the other workbenches we know use a cascade of  Asterisk "GoToIfTime" constructs to see if a timer should fire.  SARK does it differently.  Whenever a call arrives, SARK looks at the open/closed flag in the matching tenant record and simply executes the open or closed route depending upon the value.   That's all the processing we do during call setup. 

Of course, this begs the question, how do the flags get set?   There is a little php routine which runs once a minute and sets all the open/closed flags for all the tenants based upon the values in the timer window.   The routine can be found at /opt/sark/generator/srktimer.php.

It's not complex, it just walks through the database time records in the table called "dateseg" and does a truth comparison for each one. 

The routine gets its "Now" values from the php time function.  Maybe that is where the disparity lies,  I'm not sure,  but you can fool around with the routine to see what's happening.   Just run it from the command line as often as you like, it's idempotent so you shouldn't hurt anything.

Code Select Expand

php /opt/sark/generator/srktimer.php

[compsos]

Thanks, Set the debug on which outputted
Array
(
)
Array
(
    [default] => Array
        (
            [cluster] => default
            [route] =>
            [routeclass] =>
        )

)
Array
(
    [pkey] => default
    [routeoverride] =>
    [routeclassoverride] =>
)
DAY FAILS  - WE'RE OPEN sat
DAY FAILS  - WE'RE OPEN sun
TSTART 1800
TEND 0959
DATE - 0916
Invert TIMESPAN MATCHED  - WE'RE CLOSED default
Array
(
    [dateSeg383022] => IDLE
    [dateSeg204082] => IDLE
    [dateSeg288611] => *INUSE*
)
root@pbx:~# date
Thu 15 Nov 08:16:53 AEST 2018
So I assume 'DATE -0916' is really time but note the date command is correct. DATE is not. So where or how does the DATE get populated into the DB? And why would it not just be a straight system date call?

[compsos]

Found it.

The php.ini had not picked up the timezone. Had to manually edit the /etc/php/7.0/cli/php.ini file. It was blank. So now Date is correct.

Uncomment Line 924 and insert your timezone data
date.timezone =

Would have expected a blank timezone to default to UTC (ie) -10hours.

Will monitor to see if it stays correct.

Thanks.

[sysadmin]

Excellent debugging.

I had guessed it might be the PHP time function but did not have time to debug it.   I'll do a bit more research to see how/if we can automate it at install time.