Problem with Time Conditions module not switching

I have a time condition in the dialplan so inbound calls are routed to the time condition and then to a target based on the time check. So the timeplan is say, Monday-Friday 09:00-17:00. Calls that come in at 16:59 are routed to the ‘day’ section, but a call that comes in at 17:00 is also routed to the day section.

As is a call that arrives at 17:01.

Calls that arrive at 17:02 are correctly routed to the night section, so it looks like the time condition is two minutes out?

I’m checking the time on the server and on the admin client. I can work around this by setting the time conditions two minutes early.

I’ve yet to check the start time but I’ll do that shortly. Can anyone else confirm this fault?

EDIT: I’ve checked and the start time is perfect. A call at 08:59.59 is ‘night’ and a call at 09:00.01 is ‘day’

try instrumenting the code with a debug statement using something like System() spitting the time out into a log. This translates directly to Asterisk time functions so if there is an issue we’ll have to check with Asterisk and on their bug tracker to see what might be up. (Also check the dialplan code to make sure it is in fact being properly generated by FreePBX).

The section on extensions_additional.conf show as:

[timeconditions]
include => timeconditions-custom
exten => 1,1,System(/bin/date)
exten => 1,n,GotoIfTime(08:00-17:58|mon-fri|1-31|jan-dec?ivr-4,s,1)
exten => 1,n,Goto(timeconditions,2,1)
exten => 2,1,GotoIfTime(08:00-12:58|sat|1-31|jan-dec?ivr-4,s,1)
exten => 2,n,Goto(ivr-3,s,1)

; end of [timeconditions]

Which is exactly how I have them currently set in the GUI.

I’m looking for a way to show the current time in the console while a call happens but so far it’s not working. I’ll check Asterisk known issues while I play with that as it does indeed look like it’s not a freepbx issue.

try something like:

exten =>1,1,Noop(TIME: ${STRFTIME(${EPOCH},,%Y%m%d-%H%M%S)})

Thanks for that, heres some logs:

Call placed at 16:59 - Result is DAY
    -- Executing [[email protected]:1] NoOp("SIP/8166-b63082a0", "TIME: 20080213-16:59.23") in new stack
    -- Executing [[email protected]:2] GotoIfTime("SIP/8166-b63082a0", "08:00-17:00|mon-fri|1-31|jan-dec?ivr-4|s|1") in new stack
    -- Goto (ivr-4,s,1)
Call placed at 17:00 - Result is DAY
    -- Executing [[email protected]:1] NoOp("SIP/8166-b63055a8", "TIME: 20080213-17:00.17") in new stack
    -- Executing [[email protected]:2] GotoIfTime("SIP/8166-b63055a8", "08:00-17:00|mon-fri|1-31|jan-dec?ivr-4|s|1") in new stack
    -- Goto (ivr-4,s,1)
Call placed at 17:01 - Result is DAY
    -- Executing [[email protected]:1] NoOp("SIP/8166-b6328cc8", "TIME: 20080213-17:01.18") in new stack
    -- Executing [[email protected]:2] GotoIfTime("SIP/8166-b6328cc8", "08:00-17:00|mon-fri|1-31|jan-dec?ivr-4|s|1") in new stack
    -- Goto (ivr-4,s,1)
Call placed at 17:02 - Result is NIGHT
    -- Executing [[email protected]:1] NoOp("SIP/8166-b6328cc8", "TIME: 20080213-17:02.12") in new stack
    -- Executing [[email protected]:2] GotoIfTime("SIP/8166-b6328cc8", "08:00-17:00|mon-fri|1-31|jan-dec?ivr-4|s|1") in new stack
    -- Executing [[email protected]:3] Goto("SIP/8166-b6328cc8", "timeconditions|2|1") in new stack
    -- Goto (timeconditions,2,1)

Looks like the times being seen are correct and asterisk is just getting it wrong - I’m still looking at the fault lists and changelogs for asterisk, not seen anything relevant yet.

For reference, I;m using asterisk 1.4.17

From reading the bug report, I’ve no idea if it’s supposed to be fixed or not, but it’s clearly known:

http://bugs.digium.com/view.php?id=6230#39615