On 28.01.2022 18:46, Kingsley Tart wrote:
+--------+---------+--------------+---------------------------+----------+---------+--------+----------+--------------+--------------+-------------+
| ruleid | groupid | prefix | timerec | priority |
routeid | gwlist | sort_alg | sort_profile | attrs | description |
+--------+---------+--------------+---------------------------+----------+---------+--------+----------+--------------+--------------+-------------+
| 173 | 0 | 441476292509 | 20220124T000000|404999 | 1 | NULL
| #gw9 | N | NULL | endpoint=gw9 | NULL |
| 174 | 0 | 441476292509 | 20220128T163000|504096247 | 1 | NULL
| #gw1 | N | NULL | endpoint=gw1 | NULL |
+--------+---------+--------------+---------------------------+----------+---------+--------+----------+--------------+--------------+-------------+
Hi Kingsley,
The 3.1 release is the final release using the classic timerec support.
Since 3.2, the time recurrence parsing and evaluation is much more
consistent and well-tested across all modules using this concept.
Still, in order to fix your issue on 3.1, the format I linked is the
ONLY way in order to define an [A, B) interval, where B is
non-inclusive. Looking at your examples, both strings seem wrong
("20220124T000000|404999" and "20220128T163000|504096247"), because of
the poorly formatted DURATION field -- the second one. Example correct
strings for that field: P7W (7 weeks), PT24H (24 hours), PT1M30S (1
minute 30 seconds), etc.. The official format is detailed here^[1] .
Fun fact: MySQL's Galera engine uses this exact format as well, in order
to represent time durations in its config file.
[1]: https://datatracker.ietf.org/doc/html/rfc5545#section-3.3.6
Hope this helps,
--
Liviu Chircu
www.twitter.com/liviuchircu |www.opensips-solutions.com
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
