Summary:ASTERISK-15514: gotoiftime does not work as expected for date range
Reporter:nick_lewis (nick_lewis)Labels:
Date Opened:2010-01-25 11:53:59.000-0600Date Closed:2011-06-07 14:00:37
Versions:Frequency of
Description:In the middle of December I set a time condition using the gotoiftime dialplan application from Dec24 to Jan3. It worked correctly over this holiday period and switched off after Jan3. However on Jan24 it switched on again. This is not the operation that I expected.


Initially I thought that the problem may be due to the year change but I now think that periods within one year may be equally affected. In ast_check_timing I would expect to see a month/date calculation similar to the hour/minute one but the month match and the date match appear to be done independently.

I my assumptions are correct then the date range of Jul29-Aug3 will be incorrectly interpreted as Jul1-Jul3,Jul29-Jul31,Aug1-Aug3,Aug29-Aug31

Comments:By: Leif Madsen (lmadsen) 2010-01-26 07:53:02.000-0600

I see you're filing this against 1.2.X which does not receive bug fixes. Is this an issue on 1.4.X+?

By: nick_lewis (nick_lewis) 2010-01-26 07:55:59.000-0600

I have looked at pbx.c in trunk and problem appears still to be present

By: Tilghman Lesher (tilghman) 2010-02-01 16:35:54.000-0600

What syntax are you using?  I don't see a way to do what you're suggesting using the current syntax without using 2 separate lines.

By: nick_lewis (nick_lewis) 2010-02-02 04:21:13.000-0600

My point is that the syntax that would appear to be the way to do it does not do it. For example
  exten => 1,1,GotoIfTime(*,*,24-3,dec-jan?timeconditions,2,1)
is not interpreted as a single range dec24-jan3 but instead interpreted as the less expected dec1-3, dec24-jan3, jan24-31

The behaviour of some other settings seem to sit better with human expectations. For example
  exten => 1,1,GotoIfTime(09:30-11:59,*,*,*?timeconditions,3,1)
is interpreted as a single range 09:30-11:59 and not interpreted as 09:30-09:59, 10:30-10:59, 11:30-11:59 (though I accept that the syntax is different)

I suggest that the current operation for date/month is:
(i) at odds with user's expectations
(ii) never the wanted behaviour
(iii) should be changed so that the current syntax provides useful date/month ranges

If this is not acceptable then alternatively perhaps the date field syntax could be augmented with optional "mth/" to better support ranges e.g.

exten => 1,1,GotoIfTime(*,*,dec/24-jan/3,*?timeconditions,3,1)

By: David Woolley (davidw) 2010-02-02 04:36:10.000-0600

It's working the way that Unix cron works, so I think it is working as expected.

By: nick_lewis (nick_lewis) 2010-02-02 04:48:31.000-0600

As far as I am aware cron does not support ranges of any kind. So I am unclear as to how cron influences my request to have date ranges operate like time ranges

By: David Woolley (davidw) 2010-02-02 04:56:24.000-0600

From man 5 crontab on CentOS 5.3 (Final):

      Ranges of numbers are allowed.  Ranges are two numbers separated with a
      hyphen.  The specified range is inclusive.  For example,  8-11  for  an
      "hours" entry specifies execution at hours 8, 9, 10 and 11.

Or for SCO OpenServer:

  o two numbers separated by a minus (indicating an inclusive range)

By: nick_lewis (nick_lewis) 2010-02-02 05:10:00.000-0600

Ok perhaps I should have use the word "period" where as cron has "instants"

For example in cron
30 09-11 * * *
means the instants 09:30,10:30,11:30

but in gotoiftime
means the period from 09:30 to 11:30

I think that date periods in gotoiftime should work in the same way as time periods

By: Tilghman Lesher (tilghman) 2010-02-02 10:10:33.000-0600

You may think so, but this is a feature request, not a bug report.  The fact is that it does not work this way, and you've simply misunderstood the syntax.