We have configured a time group that only contains a starting day, ending day, starting month and ending month. This is to indicate the time period our office would be closed for Christimas.
Unfortunately we get a false positive on the timematch.
As you can see in the settings the Time Match should not be True on the 24th of January. But when we call on the the 24th of January (today) this is logged in the logs and we receive the xmas message:
546885[2022-01-24 12:11:39] VERBOSE[62998][C-0000071c] pbx.c: Executing [10@timeconditions:3] NoOp("PJSIP/ADRA-000015b5", "TIMENOW: 12:11,Mon,24,Jan") in new stack
546886[2022-01-24 12:11:39] VERBOSE[62998][C-0000071c] pbx.c: Executing [10@timeconditions:4] NoOp("PJSIP/ADRA-000015b5", "TIMEMATCHED: TRUE") in new stack
546887[2022-01-24 12:11:39] VERBOSE[62998][C-0000071c] pbx.c: Executing [10@timeconditions:5] GotoIfTime("PJSIP/ADRA-000015b5", "*,*,24-9,dec-jan?truestate") in new stack
Is this a bug or did we do something wrong. The message worked fine in between the dates 24-december and 9-january. But today we received messages that the X-mas message is played.
You did something wrong. Each field is matched separately, so your configuration will match from December 1st to December 9th, December 24th to December 31st, January 1st, to January 9th, and January 24th to January 31st. This is the same logic as Unix has been using since the 1980s,or earlier, for crontab entries.
This logic can be particularly useful if you include day of week, as you can define rules for Friday 13th, or for the second and Thursday, etc.
As @david55 mentioned. By setting up December and January on the same Time Group entry the system doesn’t have the ‘intelligence’ to know that you are referring to December 2021 and January 2022.
Keep them on separate entries and avoid using Start date - End date → Higher value - lower value. It will cause problems and false positives as noted.
