Hi Daniel,
We were looking into the code and the situation related with the last day
of the month seems to be on the following code on function check_byxxx:
if(_atp->t.tm_mday == (_trp->bymday->xxx[i]*_trp->bymday->req[i]+
_amp->mday)%_amp->mday + (_trp->bymday->req[i]<0)?1:0)
break;
Variable _atp->t.tm_mday contains the value parsed from the timestamp
_atp->t.tm_mday = 31
Variable _trp->bymday->xxx contains the days specified on kamailio tmrec
*bymonthday*
_trp->bymday->xxx[i]=31
Variable _trp->bymday->req specifies if the value defined is positve or
negative
_trp->bymday->req[i]=1
Variable _amp->mday contains the number of days of the month
_amp->mday=31
With this we have:
if(31 == (31*1+31)%31 + (1<0)?1:0)
Since the result is zero, there is no match.
We check the cpl_time, and we think the issue isn't solved there either.
We think the issue could be solved, adding a verification against 0 like
the following example:
if(0 == (_trp->bymday->xxx[i]*_trp->bymday->req[i]+
_amp->mday)%_amp->mday + (_trp->bymday->req[i]<0)?1:0)
break;
Best Regards,
David Gonçalves
On Tue, Mar 3, 2020 at 4:21 PM Daniel-Constantin Mierla <[email protected]>
wrote:
> Hello,
>
> a typedef cannot be a source of problems or fix them. Thanks for checking
> and testing, though, I wanted to verify it is not something eventually
> fixed in the cplc. I will try to look at it when I get a chance, given it
> is something I wrote long time ago, I may need some time to get refreshed
> with the specs and code...
>
> Cheers,
> Daniel
> On 03.03.20 16:59, David Gonçalves wrote:
>
> Hi Daniel,
>
> We compare the code from /src/lib/srutils/tmrec with the code from
> /src/modules/cplc.
>
> The algorithm used to calculate the time is the same.
>
> The main difference between them is that module /src/modules/cplc defines
> a variable *tmrec_p pointing to the same struct used by tmrec_t and, the
> functions use tmrec_p instead of tmrec_t*.
>
> Code from tmrec.h:
> typedef struct _tmrec
> {
> ...
> tr_byxxx_t *byday;
> tr_byxxx_t *bymday;
> tr_byxxx_t *byyday;
> tr_byxxx_t *bymonth;
> tr_byxxx_t *byweekno;
> int wkst;
> } tmrec_t;
>
> Code from cpl_time.h:
> typedef struct _tmrec
> {
> ...
> tr_byxxx_p byday;
> tr_byxxx_p bymday;
> tr_byxxx_p byyday;
> tr_byxxx_p bymonth;
> tr_byxxx_p byweekno;
> int wkst;
> } tmrec_t, *tmrec_p;
>
>
> We don't think this could causes the issue verified, but we decided to
> test it out.
> We change the /src/lib/srutils/tmrec to use tmrec_p pointers, test with
> the code compiled, but the behavior is the same.
>
> On Mon, Mar 2, 2020 at 4:56 PM Daniel-Constantin Mierla <[email protected]>
> wrote:
>
>> Thanks for troubleshooting further and reporting back. I actually looked
>> a bit to the code and indeed the months seems to be 0-11.
>>
>> Can you check if the code matches with the one in cpl-c module. The tmrec
>> library I wrote long time ago was embedded in cplc back in the days of
>> 2003-2005, inside the file src/modules/cplc/cpl_time.c.
>>
>> Later when other modules were added needing time recurrence matching,
>> another clone of tmrec library was made internal lib for kamailio (in
>> master now is src/core/utils/tmrec.c, older stable should be
>> src/lib/srutils/tmrec.c), but maybe some bugs were fixed in cpl-c module,
>> as it was quite used in the past, and not propagated to the stand alone lib.
>>
>> Cheers,
>> Daniel
>> On 02.03.20 17:48, David Gonçalves wrote:
>>
>> During our tests with yearly scenarios, we think we found two unexpected
>> behaviors.
>>
>> First, on the documentation, it is indicated that months can have a value
>> between 1-12. However, we think that acceptable values can be between 0-11.
>>
>> Second, we tested a yearly recurrence on the last day of the month (e.g.,
>> 31 of December, 30 of November). With a valid timestamp, we always obtain
>> not match on tmrec.
>> We tested the penultimate day of the month (e.g., 30 of December, 29 of
>> November) and, both days work with a valid timestamp.
>>
>> With these scenarios, it seems that the monthly and yearly problems
>> always occur with the last occurrence of an event.
>>
>> On Tue, Feb 25, 2020 at 11:56 AM David Gonçalves <
>> [email protected]> wrote:
>>
>>> Hi,
>>>
>>> During some tests with the module tmrec, we stumble upon an unexpected
>>> behavior of the monthly recurrence with days of the week.
>>> The last week does not match our expected date.
>>> For example, the last Monday of March 2020 is day 30 (fifth Monday of
>>> the month) however, neither the 5MO or -1MO configuration on the bday
>>> parameter match with a timestamp configured to day 30. The same situation
>>> is verified on months with only 4 weeks.
>>>
>>> To easily explain the behavior we create this configuration:
>>>
>>> $var(ts)="1584355625"; # Monday, March 16, 2020 10:47:05
>>> if(tmrec_match("20200101T090000|PT8H|monthly||1|3MO||||","$(var(ts){
>>> s.int})")) {
>>> xlog("L_INFO","Epoch $var(ts) matches with 3MO\n");
>>> }else{
>>> xlog("L_INFO","Epoch $var(ts) doesn't match with 3MO\n");
>>> }
>>>
>>> $var(ts)="1584960425"; # Monday, March 23, 2020 10:47:05
>>> if(tmrec_match("20200101T090000|PT8H|monthly||1|4MO||||","$(var(ts){
>>> s.int})")) {
>>> xlog("L_INFO","Epoch $var(ts) matches with 4MO\n");
>>> }else{
>>> xlog("L_INFO","Epoch $var(ts) doesn't match with 4MO\n");
>>> }
>>>
>>> $var(ts)="1585565225"; # Monday, March 30, 2020 10:47:05
>>> if(tmrec_match("20200101T090000|PT8H|monthly||1|5MO||||","$(var(ts){
>>> s.int})")){
>>> xlog("L_INFO","Epoch $var(ts) matches with 5MO\n");
>>> }else{
>>> xlog("L_INFO","Epoch $var(ts) doesn't match with 5MO\n");
>>> }
>>>
>>> $var(ts)="1584960425"; # Monday, March 23, 2020 10:47:05
>>> if(tmrec_match("20200101T090000|PT8H|monthly||1|-1MO||||","$(var(ts){
>>> s.int})")){
>>> xlog("L_INFO","Epoch $var(ts) matches with -1MO\n");
>>> }else{
>>> xlog("L_INFO","Epoch $var(ts) doesn't match with -1MO\n");
>>> }
>>>
>>> The results were:
>>> Epoch 1584355625 matches with 3MO
>>> Epoch 1584960425 matches with 4MO
>>> Epoch 1585565225 doesn't match with 5MO
>>> Epoch 1584960425 matches with -1MO
>>>
>>> Are we configuring the tmrec_match wrongly?
>>>
>>> --
>>>
>>>
>>> Cumprimentos / Best regards,
>>>
>>> *David Gonçalves*
>>> Research and Development Technician
>>>
>>> Phone: +351 256 370 980
>>> Email: [email protected]
>>>
>>>
>>>
>>>
>>>
>>
>> --
>>
>>
>> Cumprimentos / Best regards,
>>
>> *David Gonçalves*
>> Research and Development Technician
>>
>> Phone: +351 256 370 980
>> Email: [email protected]
>>
>>
>>
>>
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing
>> [email protected]https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>> --
>> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda --
>> www.linkedin.com/in/miconda
>> Kamailio Advanced Training - March 9-11, 2020, Berlin - www.asipto.com
>> Kamailio World Conference - April 27-29, 2020, in Berlin --
>> www.kamailioworld.com
>>
>>
>
> --
>
>
> Cumprimentos / Best regards,
>
> *David Gonçalves*
> Research and Development Technician
>
> Phone: +351 256 370 980
> Email: [email protected]
>
>
>
>
> --
> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda --
> www.linkedin.com/in/miconda
> Kamailio Advanced Training - March 9-11, 2020, Berlin - www.asipto.com
> Kamailio World Conference - April 27-29, 2020, in Berlin --
> www.kamailioworld.com
>
>
--
Cumprimentos / Best regards,
*David Gonçalves*
Research and Development Technician
Phone: +351 256 370 980
Email: [email protected]
_______________________________________________
Kamailio (SER) - Users Mailing List
[email protected]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
