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] <mailto:[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]
>> <mailto:[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
>> <http://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
>> <http://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
>> <http://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
>> <http://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]
>> <mailto:[email protected]>
>>
>>
>>
>>
>>
>>
>> --
>>
>>
>> Cumprimentos / Best regards,
>>
>> *David Gonçalves*
>> Research and Development Technician
>>
>> Phone: +351 256 370 980
>> Email:[email protected]
>> <mailto:[email protected]>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> [email protected] <mailto:[email protected]>
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
> www.twitter.com/miconda <http://www.twitter.com/miconda> --
> www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
> Kamailio Advanced Training - March 9-11, 2020, Berlin - www.asipto.com
> <http://www.asipto.com>
> Kamailio World Conference - April 27-29, 2020, in Berlin --
> www.kamailioworld.com <http://www.kamailioworld.com>
>
>
>
> --
>
>
> Cumprimentos / Best regards,
>
> *David Gonçalves*
> Research and Development Technician
>
> Phone: +351 256 370 980
> Email:[email protected]
> <mailto:[email protected]>
>
>
>
>
--
Daniel-Constantin Mierla -- www.asipto.com
www.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
_______________________________________________
Kamailio (SER) - Users Mailing List
[email protected]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
