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-0600	Date Closed:	2011-06-07 14:00:37
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	PBX/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
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. ****** ADDITIONAL INFORMATION ****** 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 09:30-11:30,*,*,* 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.