[SR-Users] Unexpected behavior on tmrec with monthly recurrence

[David Gonçalves]

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 <miconda at gmail.com>
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 <
> david.goncalves at itcenter.com.pt> 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: david.goncalves at itcenter.com.pt
>>
>>
>>
>>
>>
>
> --
>
>
> Cumprimentos / Best regards,
>
> *David Gonçalves*
> Research and Development Technician
>
> Phone: +351 256 370 980
> Email: david.goncalves at itcenter.com.pt
>
>
>
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing Listsr-users at lists.kamailio.orghttps://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: david.goncalves at itcenter.com.pt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200303/b3d815fd/attachment.html>